1  Def  e  nee  Researc  hand  R  ech  ere  he  et  de  ve  I  oppe  m  en  t 

■  ”  ■  Development  Canada  pour  la  defense  Canada 


DEFENCE 


An  Enhanced  Synthetic  Environment 
for  Maritime  Surveillance 


Nacer  Abdellaoui,  Paul  Hubbard  and  Paul  Duncan 


Defence  R&D  Canada  -  Ottawa 

TECHNICAL  MEMORANDUM 
DRDC  Ottawa  TM  2005443 
October  2005 


Canada 


An  Enhanced  Synthetic  Environment  for 
Maritime  Surveillance 


Nacer  Abdellaoui 

Defence  R&D  Canada  -  Ottawa 

Paul  Hubbard 

Defence  R&D  Canada  -  Ottawa 

Paul  Duncan 
Greenley  &  Associates 


Defence  R&D  Canada  -  Ottawa 

Technical  Memorandum 
DRDC  Ottawa  TM  2005-143 
October  2005 


©  Her  Majesty  the  Queen  as  represented  by  the  Minister  of  National  Defence,  2005 
©  Sa  majeste  la  reine,  representee  par  le  ministre  de  la  Defense  nationale,  2005 


Abstract 


The  Future  Forces  Synthetic  Environments  (FFSE)  and  the  Radar  and  Application 
Space  Technology  (RAST)  Sections  made  a  joint  effort  to  overcome  some  limitations 
associated  with  the  Synthetic  Environment  (SE)  employed  during  the  mission 
rehearsal,  in  June  2004,  for  the  Atlantic  Littoral  Intelligence  Surveillance 
Reconnaissance  Experiment  (ALIX).  During  ALIX  experiment,  the  fidelity  of  the 
different  vessels  was  deficient,  the  realism  of  the  sensors  was  poor  and  the  accuracy  of 
the  generated  contact  reports  was  incomplete.  The  realism  and  fidelity  of  the  merchant 
and  fishing  traffic  within  the  synthetic  environment  was  improved.  The  realism  of  the 
sensors  within  the  synthetic  environment  was  increased.  The  accuracy  of  the 
generated  contact  reports  was  improved. 

This  document  provides  a  summary  of  the  achievements  of  the  current  task  as  well  as  a 
list  of  lessons  learned  and  recommendations  for  organizational  and  process  changes 
within  the  FFSE  section.  Based  on  the  work  accomplished  in  the  present  task,  along 
with  the  recommendations,  a  complete  maritime  synthetic  environment,  supporting 
continuous  V&V,  for  surveillance  missions  will  soon  be  a  reality  in  the  FFSE  section 


Resume 


Les  sections  Environnements  Synthetiques  de  Forces  du  Futur  (ESFF)  et  Application 
Radar  et  Technologies  de  TEspace  (ART A)  ont  joins  leurs  efforts  pour  surmonter 
quelques  limitations  liees  a  fenvironnement  synthetique  (ES)  utilise  pendant  la 
repetition  de  mission  du  mois  de  juin  2004,  pour  les  experiences  d’ALIX.  Pendant 
f  experience  d’ALIX,  la  fldelite  des  differents  navires  etait  deficiente,  le  realisme  des 
sondes  etait  pauvre  et  f  exactitude  des  rapports  de  contact  produits  etait  imprecise.  Le 
realisme  et  la  fldelite  du  trafic  marchand  et  de  peche  dans  fenvironnement  synthetique 
ont  ete  nettement  ameliores.  Le  realisme  des  senseurs  dans  fenvironnement 
synthetique  a  ete  augmente.  L’exactitude  des  rapports  produits  de  contact  a  aussi  ete 
amelioree. 

Ce  document  foumit  un  sommaire  des  accomplissements  de  la  presente  tache  ainsi 
qu’une  liste  de  legons  apprises  et  recommandations  pour  des  changements 
organisationnels  et  de  processus  au  sein  de  la  section  ESFF.  Base  sur  le  travail 
accompli  dans  la  presente  tache,  tout  en  tenant  compte  des  diverses  recommandations, 
un  environnement  synthetique  maritime,  supportant  continuellement  V&V,  des 
missions  de  surveillance  sera  bientot  une  realite  dans  la  section  ESFF. 
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Executive  summary 


The  Atlantic  Littoral  ISR  experiment  (ALIX)  was  a  major  east  coast  Intelligence 
Surveillance  Reconnaissance  (ISR)  experiment  held  in  late  August  2004,  involving  the 
use  of  an  uninhabited  aerial  vehicle  (UAV)  and  other  ISR  sensors  including  High 
Frequency  Surface  Wave  Radar  (HFSWR)  [14].  Prior  to  the  ALIX  experiment,  a 
rehearsal  in  a  synthetic  environment  was  conducted  by  the  FFSE  section,  on  the 
DRDC  Ottawa  site.  The  Radar  and  Space  Technologies  (RAST)  Section  participated 
in  this  rehearsal  by  supplying  a  Maritime  Operations  Centre  (MOC)  using  the  Global 
Command  and  Control  System  (GCCS)  software. 

The  RAST  section  recognized  that  this  had  potential  to  support  their  on-going  work 
with  the  Multi-Sensor  Integration  within  the  Common  Operating  Environment- 
Technology  Demonstration  Program  (MUSIC-TDP)  that  deals  with  sensor  integration, 
fusion  and  its  impact  on  operator  workload  and  the  quality  of  the  constructed  RMP. 

However,  the  SE  employed  for  the  ALIX  rehearsal  was  designed  for  training  and 
mission  rehearsal  for  the  UAV,  rather  than  analysis  of  the  processes  associated  with 
maritime  surveillance  in  general,  hence  there  were  limitations  associated  with  the 
contact  reports  generated  from  the  SE  due  to  the  following  factors: 

1 .  The  realism  and  fidelity  of  the  maritime  traffic  in  the  SE  was  not  consistent 
with  what  it  is  normally  seen.  This  was  corrected  by  constructing  a  database 
of  representative  traffic  for  one  twenty-four  hour  period. 

2.  Realism  of  the  sensor  suite  was  insufficient,  (e.g.  “cookie-cutter”  High 
Frequency  Surface  Wave  Radar  models  were  used  and  sensors  such  as  the 
Automatic  Identification  System,  ELINT  and  other  airborne  platforms  were 
missing).  This  was  corrected  by  including  well,  unclassified,  sensors  in  the 
SE,  and  modeling  some  tracking  systems  and  probabilistic  detections  in  the 
sensor  models  to  increase  fidelity. 

3.  The  accuracy  of  the  generated  contact  reports  was  also  insufficient,  e.g.  many 
of  the  fields  in  the  OTH  messages  were  either  incorrect  or  not  populated.  This 
was  corrected  with  a  review  of  the  message  fields  followed  by  changes  to  code 
and  standard  operating  procedure  for  the  human  operators  in  the  SE. 

It  was  noted  during  the  execution  of  this  work  that  the  FFSE  section  is  missing  some 
traditional  organizational  tools,  most  notably  knowledge  management  and  process 
infrastructure.  The  following  recommendations  are  made: 

1 .  Increase  the  modularity  in  the  maritime  SE  by  developing  two  stand-alone 
HLA  components,  a  Commercial  Traffic  Server  (CTS)  and  an  East  Coast 
Maritime  Sensor  Suite  (ECMSS)  is  recommended, 

2.  Adopt  the  Carnegie  Mellon  Capability  Maturity  Model  (CMM), 
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3.  Focus  resource  and  personnel  allocation  to  maximize  individual  employees 
time  on  single  projects, 

4.  Provide  clear  role  definitions  for  all  team  members,  and 

5.  Increase  in  the  documentation  effort  across  the  board. 

A  complete  maritime  synthetic  environment  for  surveillance  missions,  supporting 
continuous  V&V,  is  envisioned  to  become  a  reality  in  the  FFSE  section.  This  must 
include  a  set  of  modular  components  for  such  aspects  as  traffic,  weather,  and  terrain 
which  can  be  re-used  in  future,  modular,  SEs.  Both  the  FFSE  and  RAST  sections  are 
planning  to  employ  the  SE  developed  in  the  present  task  in  their  future  analysis  of 
processes  within  the  maritime  operations  centre  and  the  generation  of  the  recognized 
maritime  picture,  as  well  as  in  the  evaluation  of  new  sensor  platforms,  and  the 
development  of  algorithms  for  autonomous  surveillance  systems. 


Abdellaoui,  N.,  Hubbard,  P.  and  Duncan  P.  2005.  An  Enhanced  Synthetic  Environment 
for  Maritime  Missions .  DRDC  Ottawa  TM  2005-143.  Defence  R&D  Canada  -  Ottawa. 


IV 


DRDC  Ottawa  TM  2005-143 


Sommaire 


L’exercice  ALIX,  tenue  en  aout  2004,  etait  une  importante  experience  en  termes  de 
reconnaissance,  surveillance  et  intelligence  de  la  cote.  Cet  exercice  impliquait 
futilisation  d'un  vehicule  aerien  inhabite  (UAV)  et  d'autres  sondes  ISR  comprenant, 
entre  autres,  le  radar  (HFSWR).  Avant  fexercice  ALIX,  une  repetition  dans  un 
environnement  synthetique  (ES)  a  ete  conduite  par  la  section  ESFA.  La  section 
Application  de  Radar  et  Technologies  d’Espace  (ART A)  a  participe  a  cette  repetition 
en  foumissant  un  centre  d'operations  maritimes  employant  le  logiciel  (GCCS). 

La  section  ARTA  a  identifie  le  potentiel  du  ES  pour  soutenir  leur  travail  en  cours  avec 
le  projet  (MUSIC-TDP)  traitant  fintegration  de  senseur,  la  fusion  des  donnees  et 
F  impact  sur  la  charge  de  travail  de  foperateur  ainsi  que  la  qualite  de  F  image  RMP 
construite. 

Cependant,  FES  utilise  pour  la  repetition  d’ALIX  a  ete  con^u  pour  la  formation  et  la 
repetition  de  mission  pour  1TJAV,  plutot  que  fanalyse  des  processus  associes  a  la 
surveillance  maritime  en  general,  par  consequent  il  y  avait  des  limitations  liees  aux 
rapports  de  contact  de  FES  dues  aux  facteurs  suivants: 

1 .  Le  realisme  et  la  fidelite  du  trafic  maritime  dans  FES  n'etaient  pas  tres  conformes 
a  la  realite.  Ceci  a  ete  corrige  en  construisant  une  base  de  donnees  avec  du  trafic 
representatif  pour  une  periode  de  vingt-quatre  d'heure. 

2.  Le  realisme  des  senseurs  etait  insuffisant  (par  exemple,  le  modele  coupe-biscuit 
pour  le  HFSWR,  senseurs  manquants  tel  le  Systeme  dTdentification  Automatique 
(AIS),  Intelligence  Electronique  (ELINT)  ainsi  que  d'autres  plateformes 
aeroportees).  Ceci  a  ete  corrige  en  incluant  dans  FES,  tout  les  senseurs  connus  et 
non  classifies;  ainsi  qu’en  modelisant  quelques  systemes  de  pistage  et  detections 
probabilistes  dans  les  modeles  des  senseurs  afin  d’augmenter  la  fidelite. 

3.  L’exactitude  des  OTH-Gold  rapports  de  contact  produits,  etait  egalement 
insuffisante,  par  exemple  plusieurs  parties  des  messages  OTH  etaient  incorrectes 
ou  meme  vides.  Ceci  a  ete  corrige  avec  un  examen  de  toutes  les  donnees  de 
message  suivis  des  changements  au  code  et  a  la  procedure  d'operation  pour  les 
operateurs  dans  FES. 


La  section  ESFF  manque  quelques  outils  d’organisation,  notamment  en  gestion  de  la 
connaissance  et  en  infrastructure  de  processus.  Les  recommandations  suivantes  sont 
ainsi  faites: 

1 .  pour  augmenter  la  modularity  dans  FES  maritime,  le  developpement  de  deux 
composants  HLA  autonomes,  un  serveur  du  trafic  commercial  (CTS)  et  une  suite 
de  senseurs  maritime  de  la  cote  est  (ECMSS),  est  recommande, 
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2.  fadoption  du  modele  de  maturite  des  potentiels  (CMM)  de  Carnegie  Mellon, 

3.  attribution  plus  focalisee  de  personnel  pour  maximiser  le  temps  alloue  aux 
differents  projets, 

4.  definitions  precises  des  roles  et  taches  des  differents  membres  d'equipe,  et 

5.  une  augmentation  de  l’effort  de  documentation  a  travers  les  differentes  phases  du 
projet. 

Un  environnement  synthetique  maritime  complet  et  supportant  V&V  pour  des 
missions  de  surveillance  sera  bientot  une  realite  dans  la  section  de  l’ESFF.  Ceci  inclura 
un  ensemble  de  composants  modulaires  tells:  le  trafic,  climat  (meteo),  et  terrain.  Ces 
composants  modulaires  peuvent  etre  reutilises  a  favenir  en  ES.  Fes  sections  de  l’ESFF 
et  de  l’ARTA  projettent  d’utiliser  FES  developpe  dans  la  presente  tache  dans  leur 
future  analyse  des  processus  dans  les  centres  d’ operations  maritimes  et  pour  la 
generation  de  fimage  maritime  identifiee,  ainsi  que  dans  revaluation  de  nouveaux 
senseurs,  et  le  developpement  des  algorithmes  pour  les  systemes  de  surveillance 
autonomes. 


Abdellaoui,  N.,  Hubbard,  P.  and  Duncan  P.  2005.  An  Enhanced  Synthetic  Environment 
for  Maritime  Missions .  DRDC  Ottawa  TM  2005-143.  R  &  D  pour  la  defense  Canada  - 
Ottawa. 
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1.  Introduction  -  Maritime  Security 


With  a  coastline  close  to  250,000  km,  an  area  of  responsibility  (AOR)  of  over  11 
million  square  kilometres,  and  some  1700  ships  on  a  typical  day;  Canada  has  an 
immense  challenge  in  its  quest  for  maritime  security  [2]. 

There  are  many  various  threats  to  Canada’s  maritime  security:  they  include 
environmental  pollution,  environment  disasters,  illegal-fishing,  smuggling  (humans 
and  drugs),  illegal  use  of  the  sea  bed  resources,  and  even  terrorism.  The  goal  of 
maritime  security  is  to  know  what  is  happening  and  where  it  is  happening  in  the 
maritime  approaches  so  a  potential  asymmetric  threat  can  be  diffused  instead  of 
reacting  to  the  consequences  of  such  a  threat. 

Even  though  Canada  has  long  been  recognized  as  having  one  of  the  safest  and  secure 
maritime  systems  in  the  world;  the  events  of  September  11,  2001,  prompted  the 
government  of  Canada  (GOC)  to  take  further  steps  to  increase  efforts  to  secure  the 
maritime  system  [15]. 

The  government  has  allocated  additional  funds  for  marine  security  to  better  track 
vessels  operating  in  Canadian  waters,  increase  surveillance,  protect  marine 
infrastructure,  and  improve  domestic  and  international  coordination.  Key  measures 
include  long-range  detection  technologies;  enhanced  screening  of  ships’  passengers 
and  crews;  advanced  reporting  requirements  to  improve  the  assessment  of  potential 
risks  posed  by  vessels,  their  passengers  and  cargo;  and  measures  to  intercept  vessels 
of  concern  before  they  arrive  on  our  shores  [15]. 

Maritime  Surveillance,  which  is  fundamentally  the  observation  and  control  of  the 
territorial  waters,  cuts  across  several  areas  of  naval  warfare  such  as  Anti  Surface 
Warfare  (ASW),  Anti  Submarine  Warfare  (ASuW),  Acoustic  Warfare  (AW),  Mine 
Warfare  (MW),  Exclusive  Economic  Zone  (EEZ)  protection,  Search  And  Rescue 
(SAR),  etc;  and  encompasses  an  extensive  range  of  needs  and  capabilities.  The 
impacts  of  new  technology  and/or  new  strategy  upon  the  crew’s  workload  and 
manning  capabilities  cannot  be  fully  realized  until  after  the  technology  has  been 
installed,  or  the  strategy  has  been  applied.  While  a  novelty  may  work  perfectly  in 
theory,  and  may  perhaps  operate  appropriately  in  a  lab,  its  interaction  with  other 
systems  or  with  the  crew  can  provide  unexpected  results.  Exercising  this  novelty  in  a 
synthetic  environment  makes  it  is  possible  to  address  the  “What  if  such  and  such?” 
questions.  For  example,  in  a  synthetic  environment,  the  level  of  complexity  of 
ground  truth  can  be  adjusted  according  to  what  is  being  targeted  (developing  and 
testing  new  information-fusion  and  decision-aid  concepts  in  support  of  the  RMP  or 
training  staff  in  relevant  technologies  and  methodologies,  etc.).  Because  of  the  above, 
SE  is  being  employed  more  and  more  in  maritime  surveillance  in  Canada  and  abroad. 

1.1  The  ALIX  trial  and  the  MUSIC  TDP 

The  Atlantic  Littoral  ISR  experiment  (ALIX)  was  a  major  east  coast  Intelligence 
Surveillance  Reconnaissance  (ISR)  experiment  held  in  late  August  2004,  involving  the 
use  of  an  uninhabited  aerial  vehicle  (UAV)  and  other  ISR  sensors  including  High 
Frequency  Surface  Wave  Radar  (HFSWR)  [14].  Prior  to  the  ALIX  experiment,  a 
rehearsal  in  a  synthetic  environment  was  conducted  by  the  Future  Forces  Synthetic 
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Environment  (FFSE)  section,  at  the  DRDC  Ottawa  site.  The  Radar  and  Space 
Technologies  (RAST)  Section  participated  in  this  rehearsal  by  supplying  a  Maritime 
Operations  Centre  (MOC)  using  the  Global  Command  and  Control  System  (GCCS) 
software. 

The  RAST  section  is  currently  executing  Multi-Sensor  Integration  within  the  Common 
Operating  Environment-Technology  Demonstration  Program  (MUSIC-TDP)  that  deals 
with  sensor  integration,  data  fusion  and  its  impact  on  operator  workload  and  the 
quality  of  the  constructed  RMP.  MUSIC  provided  basic  manual  fusion  techniques  for 
the  Maritime  Operations  Centre  Halifax  to  use  during  ALIX.  The  exercise  also 
established  a  baseline  for  RMP  generation  against  which  the  performance  of  MUSIC’S 
automated  fusion  methods  can  be  assessed  [4].  The  other  role  of  the  MOC  during  this 
experiment  was  to  generate  an  RMP  based  on  the  contact  reports  generated  by  the  SE, 
where  data  fusion  was  attempted  [5]. 

ALIX  trial  authorities  have  recognized  that  their  data  set  will  be  a  key  product  for 
“after  the  fact”  data  fusion  research,  with  MUSIC  as  one  of  the  primary  customers  for 
this  post-processing  effort.  Because  ALIX  occurred  early  within  the  MUSIC  project 
schedule,  it  was  not  possible  for  the  TD  to  demonstrate  an  automated  fusion  capability 
during  these  experiments.  However,  the  ALIX  data  set  will  be  important  to  the  TD 
throughout  its  life,  and  during  the  experiment,  the  MUSIC  team  examined  basic 
aspects  of  fusion  and  associated  operator/system  metrics  that  can  be  leveraged  during 
the  remainder  of  the  TD  [14]. 

1.2  Maritime  Operations  Centre 

There  is  a  common  misconception  that  surveillance  and  command  and  control  of  naval 
forces  are  directed  by  an  operations  centre.  The  Maritime  Operations  Centre  has  as  a 
primary  mandate  the  task  of  compiling,  updating  and  managing  the  Recognized 
Maritime  Picture  (RMP).  This  dynamic  product  is  the  collation  of  all  shipping 
detected,  identified  and  tracked  in  Canada’s  sea  lanes  of  approach.  The  Maritime 
Operations  Centre  neither  commands  nor  controls  operations  but  functions  as  a  conduit 
to  deployed  forces  and  outside  agencies.  It  is  manned  by  relatively  junior  personnel; 
consequently  it  has  neither  the  capability  nor  the  delegated  authority  to  provide 
operational  direction  other  than  to  relay  information  to  planning  authorities  and  to 
those  senior  officers  vested  with  such  powers.  However,  the  direction  of  surveillance, 
the  command  and  control  of  operations,  and  the  formulation  of  emergency  responses  to 
emergent  crisis  situations  is  the  responsibility  of  the  Assistant  Chief  of  Staff  Plans  and 
Operations  and  his  staff. 


1.3  Recognized  Maritime  Picture 

A  plot  compiled  to  depict  maritime  activity  (at  least  in  the  naval  context)  is  referred  to 
as  a  Recognized  Maritime  Picture,  see  Figure  1.  The  term  “recognized”  is  used  to 
indicate  that  the  picture  has  been  evaluated  prior  to  its  dissemination.  In  other  words, 
rather  than  having  stations  simply  pass  data  between  themselves,  there  is  a  central 
authority  to  whom  data  is  forwarded  for  compilation,  evaluation  and  dissemination. 
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The  picture  is  built  from  all  data  sources  that  can  be  accessed  which  relate  to  maritime 
traffic  in  the  area  of  concern.  Normally,  a  data  source  will  frequently  provide  position 
and  identity  information  of  a  given  vessel;  another  source  might  provide,  less 
frequently,  additional  data  such  as  the  vessel’s  owner,  cargo  and  other  background 
information.  Assembled  into  the  picture,  all  this  data  provides  an  awareness  of  the 
volume,  location  and  nature  of  shipping  activity  and  provides  a  background  for  deeper 
analysis  of  trends  and  vulnerabilities.  Data  sources  are  identified  through  actively 
seeking  them  out  and  then  collecting  and  assembling  the  data  in  a  format  suitable  for 
exchange  between  numerous  partners.  The  recognized  maritime  picture  is  compiled  by 
fusing  all  this  information  and  combining  it  with  reports  from  naval  ships  and  aircraft 
in  their  areas  of  operations. 


Figure  1.  An  example  of  visualization  of  the  Recognized  Maritime  Picture  with  the  Global  Command  and 

Control  System  (GCCS). 


The  challenge  of  this  process  is  to  create  a  structure  under  which  all  the  surveillance 
data  from  these  systems  and  platforms  is  fused  together  to  tell  the  whole  story  on  each 
vessel.  Surveillance  plus  intelligence  plus  fusion  equals  situational  awareness. 
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1.4  Motivation 


The  role  of  the  MOC  during  the  ALIX  SE  work  was  to  generate  an  RMP  based  on  the 
contact  reports  generated  by  the  SE.  The  following  advantages  to  using  a  synthetic 
environment  were  observed  during  the  SE  ALIX  rehearsal: 

•  it  created  a  realistic  real-time  environment  in  which  RAST  section  could  test 
out  some  of  their  fusion  procedures; 

•  the  use  of  real  operators  allows  them  to  assess  human  factors  issues;  and 

•  most  importantly,  the  abbreviated  nature  of  the  trial  could  allow  them  to  repeat 
the  trial  under  different  conditions. 

The  RAST  section  recognized  that  SE  ALIX  had  potential  to  support  their  on-going 
work  with  the  MUSIC  TDP  in  dealing  with  sensor  integration,  data  fusion  and  its 
impact  on  operator  workload  and  the  quality  of  the  constructed  RMP.  However,  the 
SE  employed  for  the  ALIX  rehearsal  was  designed  for  training  and  mission  rehearsal 
for  the  UAV  mission,  rather  than  analysis  of  the  processes  associated  with  maritime 
surveillance  in  general.  Hence  there  were  limitations  associated  with  the  contact 
reports  generated  from  the  SE  due  to  the  following  factors: 

•  The  realism  and  fidelity  of  the  maritime  traffic  in  the  SE  was  not  consistent 
with  what  it  is  normally  seen. 

•  The  realism  of  the  sensor  suite  was  insufficient,  (e.g.  “cookie-cutter”  High 
Frequency  Surface  Wave  Radar  models  used  and  missing  sensors  such  as  the 
Automatic  Identification  System,  ELectronic  INTelligence  (ELINT)  and  other 
airborne  platforms  were  missing). 

•  The  accuracy  of  the  generated  contact  reports  was  also  insufficient,  e.g.  many 
of  the  fields  in  the  OTH  messages  were  either  incorrect  or  not  populated. 

•  The  Own  Ship  Weather  Messages  (OSWEX)  messages  reported  by  some 
merchant  vessels  to  report  their  locations  every  6  hours  when  in  the  Open 
Ocean  are  not  generated. 

The  ultimate  goal  of  such  research  program  is  the  development  of  a  modular  synthetic 
environment  that  can  be  re-used  in  other  projects,  and  in  particular  support  capability 
management  [4]  of  maritime  ISR  suites.  The  modularity  is  key  to  incremental 
increases  in  fidelity  or  insertion  of  new  technologies.  The  FFSE  section  is  exploring 
two  federates  or  servers  (which  are  being  studied  at  FFSE  and  the  exact  architecture  is 
being  decided)  to  provide  realistic  commercial  traffic  and  sensor  systems.  Other 
components  include  a  weather  server,  a  visual  database,  a  terrain  server,  a 
collaborative  development  environment,  and  a  portal  for  experiment  participants. 
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2.  Approach 


In  order  to  increase  the  SEs  level  of  realism  this  project  targeted  three  main  areas, 
maritime  traffic  levels,  Over  The  Horizon  Gold  (OTH-Gold)  message  content  and 
sensor  fidelity. 


2.1  Maritime  Traffic 

2.1.1  Task 

ALS  Consulting  was  tasked  to  develop  unclassified,  realistic  maritime  traffic  data  for 
use  in  a  simulated  environment  scenario  for  the  generation  of  OTH  Gold  formatted 
message  reports. 

2.1.2  Deliverable 

The  deliverable  provided  was  a  list  of  vessel  waypoints  over  a  36-hour  period 
augmented  with  other  vessel  characteristics  required  for  the  generation  of  realistic 
OTH  Gold  message  reports. 

2.1.3  Data 

Two  sources  of  data  were  provided  to  use  to  develop  the  maritime  traffic  data.  The 
first  source  was  a  simulation  of  commercial  shipping  and  fishing  traffic  derived  from 
and  validated  against  the  High  Interest  Targets  (HITs)  worldwide  vessel-tracking 
database.  The  second  source  was  data  generated  from  the  ALIX  trial.  The  HITs  data, 
while  not  containing  vessel  characteristics,  does  provide  complete  track  truth  in  the 
area.  However,  the  limitations  of  the  HITs  data  include  the  following: 

Simulated 

No  sensor  information 
Data  fields  incomplete 
Motion  not  accurate 
Provides  data  for  72  hour  period 

The  ALIX  data  represents  only  actual  detections  during  the  exercise  time-frame  and 
has  the  following  attributes: 

Actual  vessel  data 
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Includes  most  sensors 


Attributes  include  name,  flag,  call-sign,  course,  speed 

Provides  data  for  two  12  hour  periods  with  a  12  hour  gap  in  between 

Accordingly,  the  scenario  design  and  data  input  uses  the  HITs  data  to  ensure  track 
truth  combined  with  the  ALIX  data  characteristics  to  generate  a  realistic  output 
through  OTH  Gold  message  reporting.  The  data  sets  were  validated  and  combined  with 
other  publicly  available  reference  materiel  to  provide  a  more  complete  identification  of 
vessel  characteristics  within  the  dataset  including  class  (where  applicable),  name,  type, 
flag,  Ship  Control  Number  (SCONUM),  course,  speed  and  time  and  location. 


2.1.4  Data  Sources 

To  develop  a  realistic  scenario  CAE  modified  the  software  to  ensure  the  following 
sensor/sources  are  included  in  the  OTH  Gold  output: 

6.  Own  Ship  Weather  Messages  (OSWEX) 

Merchant  vessel  self-reporting  by  message 
Reporting  frequency  every  8-12  hours. 

Data  includes  ship  name,  call  sign,  course,  speed,  and  position 

7.  Automatic  Identification  System  (AIS) 

Merchant  vessel  self-reporting  with  transponder 

Reporting  frequency  in  1  minute  intervals  Department  of  Fisheries  and  Oceans 

Data  includes  name,  call  sign,  course,  speed,  position,  owner,  cargo,  agent  and 
destination 

8.  High  Frequency  Surface  Wave  Radar  (HFSWR) 

Provides  tracking 

Reporting  detection  every  2-3  minutes 
Data  includes  only  positional  information 

9.  Department  of  Fisheries  and  Oceans  (DFO)  AA1 
Fishing  vessels  self-reporting  using  a  transponder 
Reporting  every  6-10  minutes. 
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Technical  information  was  provided  on  capabilities  of  HFSWR  to  fine  tune  the  model 
to  ensure  realistic  detection  and  tracking.  This  included  information  on  the  detection 
swath,  geographic  location  of  radars,  vessel  size  detection,  probability  of  detection  vs. 
sea  state  and  day  and  night  performance  capability. 

2.1.5  Vessel  Characteristics 

All  nomenclature  used  in  the  dataset  is  consistent  with  the  ALIX  experiment  and  OTH 
Gold  formatted  messages. 

Fishing  vessels  were  provided  with  a  simulated  motion  pattern  within  the  operating 
area.  There  are  two  fishing  boat  models  in  STRIVE  and  they  are  programmed  to  each 
follow  a  figure-eight  pattern  with  different  start  headings  to  give  an  element  of 
“random”  motion. 

2.1.6  Scenario 

The  scenario  runs  over  36  hours  with  the  first  12  hours  providing  a  historical  database 
for  the  remaining  24  hours.  The  scenario  comprises  91  entities: 

Fish  -  37  entities 

Merchant  -  46  entities 

Other  -  8  entities 

The  datasets  are  attached  to  this  Report. 

2.1.7  Scenario  Generation  Software 

To  facilitate  creation  of  scenarios  based  upon  maritime  traffic  data,  a  scenario 
generation  application  was  developed.  Within  the  STRIVE  synthetic  environment,  a 
scenario  is  a  collection  of  entities,  along  with  related  behavioural  and  geographic 
information.  The  scenario  generation  tool  enables  the  addition  of  realistic  maritime 
traffic  to  an  existing  scenario,  or  the  creation  of  a  new  scenario  based  solely  upon  the 
maritime  traffic  dataset  provided.  Since  behaviour  models  are  required  in  order  to 
properly  enable  sensors  and  generate  contact  reports,  it  is  anticipated  that  the  most 
common  use  of  the  scenario  generator  will  be  to  add  maritime  traffic  to  a  scenario 
which  already  contains  the  appropriate  sensor  bearing  entities,  e.g.  coastal  radar  or 
UAVs. 

The  input  to  the  scenario  generator  application  is  maritime  data  that  has  been  formatted 
in  Comma  Separated  Value  (CSV)  format.  Based  upon  this  data  the  Scenario 
Generator  creates  a  scenario.  It  maps  the  tracks  to  STRIVE  entity  types  based  upon 
the  type  of  ship  and  what  sensors  are  present  on  the  vessel.  Waypoints  are  generated 
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for  the  ship  based  upon  the  track  data.  Table  1  contains  the  mapping  made  between 
the  traffic  dataset  and  STRIVE  entities. 


Table  1.  Traffic  dataset  -  STRIVE  entities  Mapping 


Code 

Target  Type 

STRIVE  Entity 

DDG 

Destroyer,  Guided  Missile 

Krivak  frigate 

AGB 

Icebreaker 

Krivak  frigate 

WAGL 

Buoy  Tender,  Coast  Guard 

Krivak  frigate 

TUG 

Tug 

Generic  Ship 

BLK 

Cargo,  Bulk 

Container  Class 

CGO 

Cargo,  Dry 

Container  Class 

TMB 

Merchant  Ship,  Bulk 

Container  Class 

TMCS 

Merchant  Ship,  Container 

Container  Class 

TMD 

Merchant  Ship,  Dredger 

Container  Class 

TME 

Merchant  Ship,  RO/RO 

Container  Class 

TMF 

Merchant  Ship,  Ferry 

Container  Class 

TMGS 

Merchant  Ship,  Scientific 

Container  Class 

TMK 

Merchant  Ship,  Cable  layer 

Tanker 

TMO 

Merchant  Ship,  Tanker 

Tanker 

TMOS 

Merchant  Ship,  special  liquids 

Container  Class 

FISH 

Fisher 

Trawler  (Blue) 

Other 

Undefined  type  defaults  to  Generic 
Ship. 

Generic  Ship 

For  ships  containing  sensors,  the  sensor  type  is  appended  to  the  entity  name.  For 
example,  a  Fisher  with  an  AA1  sensor  would  be  named  “Trawler  (Blue)  AA1”. 

A  behaviour  model  is  assigned  to  the  entity  based  upon  what  equipment  is  present.  If 
no  equipment  is  present,  no  behaviour  model  will  be  assigned,  and  the  STRIVE  entity 
will  follow  its  default  behaviour,  which  is  to  follow  the  assigned  waypoints. 
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For  fishing  vessels,  no  track  data  is  present  in  the  original  dataset,  and  a  behaviour 
model  is  assigned  instead  which  causes  them  to  navigate  in  a  figure-eight  pattern 
around  their  starting  point. 

It  was  not  possible  to  map  all  of  the  information  present  within  the  maritime  traffic 
dataset  in  to  the  corresponding  STRIVE  entity.  For  example,  STRIVE  entity  names 
are  limited  to  10  characters,  so  any  characters  beyond  this  limit  will  be  lost.  There  are 
not  general  purpose  fields  in  which  to  store  additional  information,  so  it  was  not 
possible  to  store  all  of  the  information  associated  with  an  entity.  Also,  within 
STRIVE,  the  country  associated  with  an  entity  type  can  not  be  changed,  so  that  the 
only  way  to  properly  map  flags  would  be  to  create  hundreds  of  entities  associated  with 
the  permutations  of  flag  and  entity  type. 

This  information  is  present  within  the  AIS  sensor  model  developed  by  CAE,  but  is  not 
accessible  from  within  STRIVE  Studio.  The  fields  affected  are  as  follows: 

HIT  ID 

Class 

Category 

Flag 

SCONUM 

UID 

International  Radio  Call  Sign 

In  order  for  the  Scenario  Generation  software  to  operate  properly,  all  of  the  required 
entity  types  and  behaviours  must  be  present  within  the  particular  instance  of  STRIVE. 
To  use  the  software,  the  following  command  should  be  issued  from  within  the 
c:\FFSE106\bin  directory: 

scenariogenerator  <data  file>  [old  scenario]  <new 
scenario> 

The  data  file  should  point  to  a  properly  formatted  CSV  file  containing  the  maritime 
traffic.  The  old  scenario  argument,  if  present,  is  the  name  of  the  STRIVE  Scenario 
which  is  used  as  basis  for  the  new  scenario.  The  new  scenario  argument  is  the  name  of 
the  new  scenario  to  generate.  These  names  should  correspond  to  the  name  of  the 
STRIVE  Scenario  as  displayed  within  the  STRIVE  Studio  application.  If  the  name 
contains  spaces,  it  should  be  enclosed  within  quotation  marks. 


2.1.8  Sub-Banding 

The  version  of  STRIVE  being  used  by  DRDC  Ottawa,  STRIVE  1.8. 8.0  Beta,  could  not 
support  the  number  of  entities  required  for  realistic  maritime  traffic.  It  was  estimated 
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that  it  would  need  to  be  able  to  support  upwards  of  100  entities  with  sensor  models, 
and  the  current  version  was  limited  to  approximately  40  entities. 

It  was  noted  that  most  of  the  maritime  traffic  had  a  quite  limited  range  of  behaviour, 
and  so  could  be  updated  less  frequently  than  the  overall  simulation.  For  example,  all 
of  the  maritime  traffic  excluding  fishing  vessels  would  simply  follow  a  predefined 
route  for  the  duration  of  the  simulation.  In  most  cases,  these  routes  consisted  of  only  a 
few  waypoints.  In  this  case,  there  is  no  need  for  the  simulation  to  update  the  state  of 
these  entities  as  often  as  it  would  for  a  more  dynamic  entity  such  as  an  UAV.  By 
reducing  the  update  rate  associated  with  quasi-static  entities,  less  processing  is 
required  for  each  update  of  the  simulation  state,  allowing  STRIVE  to  accommodate 
more  entities. 

Work  was  done  by  CAE  to  investigate  both  the  limitations  of  the  current  version  of 
STRIVE,  as  well  as  to  develop  a  sub-banding  approach  to  entity  updates,  allowing  for 
certain  entities  to  be  updated  less  frequently  than  others.  This  work  involved  replacing 
the  dynamics  models  of  certain  entities  with  newly  developed  dynamics  models  which 
would  support  a  slower  update  rate. 

STRIVE  updates  dynamics  models  at  a  fundamental  rate  of  40  hertz.  This  has  been 
sub-divided  into  5  bands.  The  dynamics  models  for  the  ships  have  been  set  to  update 
in  one  of  these  bands,  which  gives  and  effective  update  rate  of  8  hertz. 

The  use  of  these  dynamics  models  is  dependent  upon  having  two  environment 
variables  set.  These  are  outlined  in  Table  2. 


Table  2.  Sub-banding  Environment  variables 


ENVIRONMENT  VARIABLE 

PURPOSE 

CGF_DYNAMICS_SUBBANDING_LEVEL 

Must  be  set  to  1  to  enable  sub-banding. 

CGF_SHIP_DYNAMICS_SUBBANDING_LEVEL 

Band  in  which  to  update. 

2.2  OTH-Gold  Messages 

The  second  area  targeted  in  order  to  increase  the  level  of  realism  was  the  OTH-Gold 
messages.  Based  on  message  formats  provided  by  DRDC  Ottawa  taken  from  the 
ALIX  trial  CAE  modified  the  existing  OTH-Gold  plugin  to  support  the  new  message 
formats.  This  involved  modifications  to  the  CgfMdlCom.dll  library. 

These  modifications  include  the  following  information: 

Adding  XCTC  format  to  contact  reports. 

Adding  OSWEX  report. 
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Adding  AIS  report. 

Adding  AA1  report. 

Adding  HFSWR  report. 

In  order  for  the  OTH-GOLD  plugin  to  send  messages  to  a  specific  location,  the  GCCS 
Location  environment  variables  must  be  set  as  shown  in  Table  3. 

Table  3.  GCCS  Location  Environment  Variables 


ENVIRONMENT  VARIABLE 

PURPOSE 

GCCSIP 

IP  Address  of  the  GCCS  Computer. 

GCCSPort 

Port  on  which  to  receive  OTH-GOLD  messages. 

The  STRIVE  exercise  should  be  running  before  the  OTH-GOLD  gateway  is  started.  It 
can  be  started  by  means  of  a  batch  file,  or  by  the  following  command: 

SfxCp  -type  Sfx::OthGoldGateway 


2.3  New  Sensor  Models 

2.3.1  HFSWR 

The  HFSWR  model  was  created  by  CAE  to  alter  its  coverage  and  sensitivity  based  on 
information  provided  by  DRDC-Ottawa.  The  new  area  of  coverage  is  a  120  degree 
cone  with  a  minimum  detection  range  of  50  nautical  miles  and  the  maximum  detection 
range  of  220  nautical  miles.  The  probability  of  detection  changes  from  100% 
detection  at  the  center  of  the  cone  coverage  to  20%  probability  of  detection  at  the  edge 
of  the  cone. 

Probability  of  detection  is  also  affected  by  time  of  day  based  upon  either  day  or  night 
time  conditions.  Day  is  considered  to  last  from  6am  to  6pm.  Under  night  time 
conditions  the  effective  range  of  the  target  is  increased  by  30  nautical  miles.  The 
probability  of  detection  is  dependent  on  the  range  of  the  target,  as  well  as  its 
orientation  with  respect  to  the  radar. 

The  HFSWR  uses  the  visual  contrast  of  the  target  to  compute  its  Radar  Cross  Section 
(RCS).  However,  it  is  necessary  for  the  target  to  have  a  RCS  value,  even  though  the 
HFSWR  model  does  not  make  use  of  it,  in  order  for  it  to  be  considered  a  radar  target. 
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2.3.2  AIS 


An  AIS  sensor  was  also  added  to  the  STRIVE  setup  by  CAE.  The  AIS  sensor  consists 
of  two  parts,  a  transmitter  on  the  vessels  and  a  transmitter  on  the  aircraft.  The  aircraft 
with  the  transmitter  requires  a  rule  set  to  look  for  vessels  with  an  AIS  transmitter  and 
generate  contact  reports  for  them.  The  AIS  transmitter  on  the  vessels  contains  extra 
information  not  normally  associated  with  the  STRIVE  entity  that  is  needed  to  generate 
the  AIS  contact  report.  This  includes  vessel  class,  type,  category,  call  sign  and  flag.  In 
order  for  the  line  of  sight  calculation  to  work  correctly  for  the  AIS  receiver/transmitter, 
the  entity  must  be  located  in  a  part  of  the  world  covered  by  the  terrain  database. 

2.3.3  AA1 

An  AA1  sensor  was  also  added  to  the  STRIVE  setup  by  CAE.  The  AA1  sensor 
consists  of  two  parts,  a  transmitter  on  the  vessels  and  a  transmitter  on  the  aircraft.  The 
aircraft  with  the  transmitter  requires  a  rule  set  to  look  for  vessels  with  an  AA1 
transmitter  and  generate  contact  reports  for  them.  In  order  for  the  line  of  sight 
calculation  to  work  correctly  for  the  AA1  receiver/transmitter,  the  entity  must  be 
located  in  a  part  of  the  world  covered  by  the  terrain  database. 


2.3.4  Doctrines  for  the  New  Sensors 

In  order  for  the  HFSWR,  AIS,  AA1  and  OSWEX  contact  reports  to  be  generated  the 
appropriate  doctrines  must  be  attached  to  the  appropriate  STRIVE  entities.  Copies  of 
these  doctrines  are  included  in  the  appendices.  The  HFSWR  entity  requires  “An 
HFSWR  Report”  doctrine  in  order  to  generate  OTH-Gold  messages.  Any  entity 
equipped  with  an  AIS  or  an  AA1  transmitter/receiver  requires  “An  AIS  Report”  or  “An 
AA1  Report”  Doctrine.  Similarly,  entities  that  are  supposed  to  generate  OSWEX 
reports  require  “An  OSWEX  Report”  doctrine. 

2.3.5  Entity  Modification  for  New  Sensors 

In  order  for  entities  to  be  perceived  as  having  an  AIS  or  an  AA1  transponder  the 
entities  frame  must  have  the  following  additional  information  added  to  its  frame  in  the 
associated  INI  specimen  file. 

component  =  Ship  log  signature 

Ship  Class  =  CONTAINER 

Ship  Type  =  SHIP 

Ship  Category  =  MER 

Ship  Country  Flag  =  CA 

Ship  Pennant  Number  =  NC1234 

end 
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3.  Results 


Like  in  any  other  project  where  the  results  are  measured  by  the  hits  and  misses,  this 
task  is  no  exception.  This  task  scored  well  on  some  issues  and  scored  below  average 
on  others  as  detailed  in  what  follows. 


3.1  Realism  and  Fidelity  of  Maritime  Traffic 

Realistic  data  was  obtained  about  typical  levels  of  maritime  traffic  present  within  the 
area  to  be  simulated. 

The  data  for  maritime  traffic  was  obtained  from  the  High  Interest  Targets  (HITS) 
database  and  a  Scenario  Generation  application  was  developed  in  order  to  insert 
entities  into  existing  STRIVE  Scenarios  based  upon  this  data.  There  is  a  limitation  in 
STRIVE  in  terms  of  number  of  entities  that  can  be  handled  correctly  without  degrading 
the  performance.  The  number  of  entities  is  related  to  the  computer’s  computation’s 
power  and  to  the  interaction  of  these  different  entities  with  the  environment;  in  a 
typical  situation  similar  to  the  current  project’s  scenarios,  this  number  is  thirty  to  forty. 
Unfortunately,  the  number  of  entities  for  this  task’s  scenarios  is  over  a  hundred.  In 
order  to  accommodate  more  entities  within  the  synthetic  environment,  a  sub-banding 
dynamics  model  was  developed  for  all  of  the  slow  moving  entities,  i.e.  the  ships 
present  within  the  simulation. 

3.2  Realism  of  Sensor  Suite 

The  realism  of  the  sensor  suite  was  slightly  enhanced  by  updating  the  existing  HFSWR 
sensor  model  to  more  accurately  reflect  the  coverage  of  this  radar,  but  this  sensor 
model  is  still  not  accurate  regarding  the  detection  algorithm. 

In  addition,  AIS  receiver/transponder  sensor  models  were  added  to  the  simulation  and 
attached  to  some  vessels. 

The  concern  about  the  sensors  model,  that  is  using  a  “cookie-cutter”  approach,  is  still 
outstanding  and  nothing  is  done  about  within  this  project. 

3.3  Accuracy  of  Contact  Reports 

Following  guidance  given  by  DRDC  Ottawa  technical  authorities  the  formatting  of  the 
contact  reports  was  revised  in  order  to  generate  realistic  contact  reports.  This  involved 
changing  the  formatting  of  some  of  the  fields  of  the  OTH  Gold  messages,  as  well  as 
populating  some  fields  which  were  previously  left  unpopulated. 

It  was  also  necessary  to  add  an  OSWEX  (Own-ship  Weather)  model  to  the  simulation 
to  generate  additional  positional  information. 


DRDC  Ottawa  TM  2005-143 


13 


4.  Recommendations 


4.1  External  Maritime  Traffic  Federate 

As  part  of  the  current  task,  STRIVE  was  modified  to  support  sub-banding  of  the 
update  rate  of  some  vessels,  in  an  effort  to  increase  the  number  of  entities  which  can  be 
successfully  simulated  within  STRIVE.  Although  further  work  could  be  pursued  along 
these  lines,  it  would  also  be  desirable  to  investigate  off-loading  some  of  the  processing 
from  STRIVE  by  the  creation  of  an  external  federate  to  simulate  maritime  traffic. 

Given  the  nature  of  the  maritime  traffic,  course  changes  seldom  occur  over  the  36  hour 
period  considered.  Because  of  this,  it  is  not  necessary  to  update  the  state  of  the 
simulated  entities  as  often  as  would  happen  by  default  within  STRIVE.  Also,  high 
fidelity  dynamics  and  behavioural  models  are  not  presently  required.  Because  of  this, 
the  entities  associated  with  maritime  traffic  could  be  removed  from  STRIVE,  and 
simulated  within  an  external  HLA  federate. 

The  advantages  of  this  approach  would  be  greater  control  over  the  frequency  at  which 
the  entities  update  within  STRIVE,  as  well  as  the  possibility  of  moving  the  maritime 
traffic  simulation  to  another  computer,  removing  processing  load  from  the  STRIVE 
computer. 

There  are  some  risks  associated  with  this  approach.  In  order  to  interoperate  with  the 
UAV  RTB  in  its  current  condition,  it  would  be  necessary  to  develop  a  federate  which 
will  interact  with  STRIVE  via  the  CAE  RTI.  It  is  not  certain  that  the  CAE  RTI  would 
be  able  to  handle  the  level  of  traffic  associated  with  moving  all  of  the  maritime  traffic 
to  another  computer. 

If  it  is  not  necessary  to  interoperate  with  the  UAV  RTB,  then  the  application  could  be 
simplified,  as  it  would  only  need  to  generate  properly  formatted  OTH-Gold  messages. 
In  this  case,  rudimentary  sensor  and  communication  models  would  need  to  be 
developed  in  order  to  generate  the  proper  OTH-Gold  messages  at  appropriate  times. 

4.2  OTH-Gold  Message  Router 

In  the  current  simulation  set  up,  all  OTH-Gold  messages  generated  within  STRIVE  are 
sent  on  the  STRIVE  RealGccs  communication  channel  which  then  forwards  the 
messages  immediately  to  the  GCCS  machine.  This  is  not  desirable  behaviour  for  some 
message  types.  For  example,  AA1  reports  are  produced  every  6-7  minutes  by  each 
vessel  equipped  with  a  transponder,  but  the  messages  are  supposed  to  be  collected  and 
sent  as  a  group  every  12  hours. 

In  order  to  simulate  this  behaviour,  it  would  be  desirable  to  add  an  OTH-Gold  message 
router  which  would  act  as  an  intermediary  between  STRIVE  and  the  GCCS  machine. 
The  STRIVE  exercise  variables  would  be  modified  to  point  to  this  router.  The  router 
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would  sort  OTH-Gold  message  depending  upon  their  type,  forwarding  some  of  them 
immediately  to  the  GCCS  machine,  and  collecting  others  for  later  transmission,  as 
appropriate. 


4.3  Sensor  Model  Improvements 

This  task  was  intended  to  create  a  scenario  using  realistic  maritime  traffic  data,  and  to 
demonstrate  the  scenario  working  in  the  RTB  with  existing  sensor  models.  As  part  of 
the  work  in  this  task,  it  was  decided  to  improve  the  characteristics  of  the  existing 
models,  as  previously  described.  This  section  will  outline  potential  additional  sensor 
models  and  will  recommend  priorities  for  future  development. 


4.3.1  Data  Flow  Network 

To  ensure  an  understanding  of  the  data  flow  within  this  scenario,  Figure  2  shows  the 
Maritime  Operations  Centre  and  associated  information  sources  and  networks: 


other  data  Recognized  Maritime 

/ 

Fleet  units,  agencies,  OGDs, 


Figure  2.  MOC  and  Information  Sources  &  Networks 
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4.3.2  Information  Sources 


The  following  section  describes  sources  of  information  on  maritime  traffic  in  the 
relevant  area  off-shore  eastern  Canada,  and  notes  which  of  the  information  sources 
were  modeled  in  the  present  task. 

4.3.2. 1  Merchant  vessel  OSWEX 

Some  merchant  vessels  around  the  world  report  Own  Ship  Weather  Messages 
(OSWEX)  and  their  locations  every  6  hours  when  in  the  open  ocean.  The  purpose  of 
these  messages  has  been  to  monitor  weather  conditions  throughout  the  world  to 
consolidate  and  provide  a  weather  service  to  mariners;  however  the  data  includes  ship 
name,  call-sign,  course,  speed,  and  position.  OSWEX  messages  are  sent  by  e-mail  to 
CANMARNET,  where  they  are  automatically  translated  into  GOLD  format  and 
forwarded  to  GCCS-M  with  no  MOC  operator  involvement. 

The  OSWEX  messages  were  included  in  the  scenario  as  part  of  the  present  task. 

4.3. 2.2  Canadian  Coast  Guard  INNAV 

The  Information  System  on  Marine  Navigation  (INNAV)  system  manages 
communications  from  merchant  vessels,  which  must  report  by  radio  or  email  to 
Canadian  Coast  Guard  (CCG)  shore  stations  96  hours  prior  to  arriving  at  Canadian 
ports.  The  data  includes  ship  name,  call-sign,  course,  speed,  position,  owner,  cargo, 
agent,  and  destination.  A  dedicated  INNAV  server  within  TRINITY  facilitates  full¬ 
time  exchange  between  CCG  and  DND. 

The  CCG  messages  were  not  deemed  relevant  to  the  present  task  scenario,  due  to  the 
relatively  short  duration  of  the  scenario. 

4. 3. 2. 3  Maritime  Surveillance  Aircraft 

Maritime  surveillance  aircraft  provide  visual  identification  and  confirmation  of 
contacts.  Sea  King  helicopters  are  infrequent  sources  of  contacts;  CP- 140  Aurora 
maritime  patrol  aircraft  typically  conduct  one  or  two  surveillance  flights  weekly. 
Contact  information  includes  name,  call-sign,  classification,  position,  course,  and 
speed.  Contacts  are  not  always  available  until  the  aircraft  has  landed  and  post  mission 
results  are  forwarded  to  the  MOC,  where  they  are  read  and  translated  by  GCCS-M; 
however,  the  CP- 140  can  send  messages  to  Greenwood  via  Link-1 1  HF  radio 
transmission,  which  are  then  forwarded  to  GCCS-M.  The  MOC  can  also  communicate 
by  AGA  radio  directly  to  the  CP- 140  to  supplement  Link-1 1  data  in  near  real  time. 

The  scenario  in  the  present  task  called  for  creation  of  appropriate  maritime  traffic,  so 
maritime  surveillance  aircraft  were  not  modeled. 

4. 3. 2.4  Canadian  Naval  Ships  at  Sea 

These  ships  generally  report  their  own  position  at  least  hourly  via  GCCS-M.  They  also 
report  positional  information  on  vessels  in  their  vicinity  on  an  opportunity  basis  and 
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may  conduct  courtesy  hails  to  acquire  more  information  (Civilian  ships  are  not 
required  to  provide  information  in  response  to  courtesy  hails,  but  normally  do). 

Reports  are  sent  every  24  hours,  and  include  name,  call-sign,  course,  speed,  position, 
and  activity  once  every  24  hours. 

CF  ships  were  not  included  in  the  current  task. 

4.3. 2. 5  Provincial  Airlines  (PAL) 

The  Department  of  Fisheries  and  Oceans  (DFO)  contracts  PAL  to  conduct  fisheries 
patrols  on  a  regular  basis  using  commercial  aircraft.  One  to  three  flights  are  conducted 
daily  around  the  fishing  grounds  off  Newfoundland  and  Nova  Scotia.  PAL  aircraft 
link  with  their  own  shore  bases,  and  the  MOC  taps  into  these  reports  via  the 
Surveillance  Information  Server  (SIS).  The  information  arrives  in  the  MOC  about  15 
minutes  time  late.  An  MOU  is  under  negotiation  that  would  allow  the  Navy  increased 
ability  to  task  a  PAL  flight  to  find/track  a  specific  target.  The  PAL  flights  are 
equipped  with  search  radar,  AIS  receiver,  and  EO  sensors,  and  data  includes  ship 
name,  call-sign,  course,  speed,  and  position. 

The  PAL  flights  were  not  included  in  the  current  scenario. 

4.3. 2. 6  High  Frequency  Surface  Wave  Radar  (HFSWR) 

HRSWR  is  a  Technology  Demonstration  which  provides  track  information  to  the 
MOC  where  it  is  translated  into  GOLD  format  for  GCCS-M.  The  connectivity  and 
data  availability  of  HFSWR  has  been  intermittent  given  that  the  system  is  not  an 
operational  capability  and  MOC  watch  keepers  are  therefore  not  responsible  to  ensure 
connectivity  is  maintained.  HFSWR  tracks  provide  only  positional  but  no  ID 
information,  resulting  in  a  large  number  of  “unknown”  tracks.  An  NDHQ  capital 
project  intends  to  bring  the  existing  demonstrator  sites  to  operational  status  and 
provide  several  more. 

This  capability  was  modeled  in  the  current  task. 

4.3. 2.7  Automatic  Information  System  (AIS)  transponders 

These  are  currently  fitted  on  ships  greater  than  300  tons,  and  are  becoming 
increasingly  prevalent  as  the  worldwide  regulatory  scheme  regarding  AIS  carriage  is 
progressively  implemented.  The  transponders  report  at  one-minute  intervals,  and 
information  includes  Data  includes  name,  type,  position,  course,  speed,  navigational 
status  and  other  safety  related  data.  Most  AlS-based  reports  received  by  MOC  are 
from  the  CCG  INNAV  system,  as  CCG  has  the  mandate  to  collect  the  information. 

The  AIS  receiver  was  modeled  in  the  current  task. 

4. 3. 2. 8  Electronic  Intelligence  (ELI NT) 

ELINT  primarily  provides  information  on  concentrated  areas  of  radar  activity.  It  can 
indicate  where  there  is  a  high  level  of  radar  saturation,  such  as  for  a  fishing  fleet.  This 
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resource  could  track  a  specific  vessel  in  the  form  of  an  Area  of  Probability  providing 
that  its  unique  radar  characteristics  have  been  fingerprinted.  This  may  be  difficult  to 
achieve  for  civilian  vessels,  which  frequently  lease  their  radars  and  switch  them 
routinely.  This  system  is  classified,  and  the  characteristics,  data  content,  and 
deployment  are  unknown. 

This  capability  was  not  included  in  the  current  task. 

4.3.2.9  DFOAA1 

Certain  fishing  vessels,  above  a  certain  size,  in  the  North  Atlantic  are  required  to  carry 
transponders.  The  DFO  makes  this  information  available  to  DND.  Reports  are 
typically  forwarded  to  DFO  as  block  reports  (several  hours  worth),  comprised  of  vessel 
positions  taken  at  regular  intervals  (i.e.  6  to  10  minutes).  The  DFO  forwards  this 
information  to  DND  every  12  hours. 

The  provision  of  this  information  was  not  included  in  the  current  task. 

4.3.2.10  Coast  Guard  Fax 

The  CCG  still  reports  the  locations  of  its  ships  via  a  daily  fax  to  the  MOC.  The  data  in 
the  fax  is  typically  current  within  one  or  two  hours  when  sent.  However,  it  may  take 
over  an  hour  to  manually  enter  the  data  into  the  GCCS-M. 

This  was  not  included  in  the  current  task. 

4.3.2.11  Commercial  EO  Satellites 

DSpaceD  project  Polar  Epsilon,  currently  in  Options  Analysis,  is  exploring  ways  to 
use  current  and  future  commercial  EO  satellites  [e.g.  optical  satellites  and 
RADARS AT-2]  in  support  of  maritime  surveillance.  RADARSAT-2  would  be  useful 
for  wide-area  detection  of  ships  that  are  not  emitting  and  hence  would  otherwise  go 
undetected.  Optical  satellites  would  provide  high  resolution  imagery  that  would  be 
useful  for  analysis  and  classification. 

This  was  not  included  in  the  current  task. 

4.3.2.12  Uninhabited  Aerial  Vehicles  (UAVs) 

Research,  including  annual  trials,  is  currently  underway  to  determine  CONOPS  and 
operational  utility  of  UAVs  as  maritime  surveillance  assets,  including  the  ALIX  trials 
recently  conducted  in  real  and  simulated  environments.  UAVs  would  be  equipped 
with  sensor  systems  similar  to  those  on  PAL  flights,  including  a  search  radar,  AIS 
receiver,  and  EO  sensors. 

The  RTB  includes  a  UAV  simulation,  in  the  current  task  the  transfer  of  OTH  gold 
messages  depended  on  creation  of  custom  software  for  the  interface.  As  this  was  not 
part  of  the  current  task,  this  software  could  be  created  later. 
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4.3.2.13  US  Office  of  Naval  Intelligence  (ONI) 


The  ONI  sends  locator  messages  to  TRINITY  on  various  vessels  based  on  criteria 
defined  by  ONI  and  only  partially  released  to  Canada.  These  will  include  vessels  on  a 
Vessel  of  Interest  (VOI)  list,  but  also  some  that  are  not  on  this  list. 

4.3.2.14  Transport  Canada  -  CG-300  Pollution  Surveillance  Aircraft 

The  MOC  receives  a  CG-300  Pollution  Surveillance  Aircraft  Fax  from  Transport 
Canada.  The  fax  provides  the  SDO  with  vessel  names,  positions,  ports,  vessel  types, 
times  and  dates.  The  information  is  manually  entered  into  GCCS-M. 

Not  included  in  the  current  task. 

4.3.2.15  ECAREG  (Eastern  Canada  Traffic  Regulatory  System) 

The  ECAREG  Active  Vessel  List  fax  is  a  hard  copy  of  emails  that  the  SDO  receives 
throughout  the  day  from  ECAREG  in  Dartmouth.  This  fax  is  automatically  converted 
into  GOLD  format  to  be  processed  by  GCCS-M. 

Not  included  in  the  current  task. 

4.3.3  Priority  of  Future  Model  Improvements 

In  determining  which  sources  of  information  should  have  priority  for  future  modeling, 
it  is  important  to  consider  several  factors: 

10.  The  number  of  contacts  that  the  source  will  provide.  This  will  be  based  on 
the  reporting  frequency  and  on  the  number  of  different  vessels  on  which  the 
source  would  be  expected  to  report. 

1 1 .  The  accuracy  of  the  source,  in  terms  of  the  absolute  position  of  the  contact. 

12.  The  amount  of  information  contained  in  the  reports. 

13.  The  timeliness  of  the  information,  ie,  how  long  after  the  detection  is  the 
information  reported  to  the  MOC? 

14.  The  difficulty  in  modeling  the  source.  This  will  be  significantly  affected  by 
the  required  interaction  with  other  entities  in  the  scenario.  For  example,  a 
radar  model  would  have  to  interact  with  another  entity,  and  via  a  set  of  rules 
determine  if  that  entity  should  be  reported;  on  the  other  hand,  an  own-ship 
reporting  capability  model  would  simply  create  an  appropriate  message  at  a 
regular  time.  The  radar  model  would  also  be  more  difficult  to  create  to  an 
appropriate  level  of  fidelity. 
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4.3.4  Time  Line  Analysis 


Figure  3  shows  a  four-day  time-line,  representative  of  a  possible  future  scenario  in  the 
RTB.  The  time  line  shows  how  frequently  a  single  vessel  in  the  Area  of  Interest  could 
be  expected  to  be  reported  to  the  MOC  by  the  various  sources  (those  sources  with 
time-line  information).  This  figure  clearly  shows  that  the  Navy  own  ship,  HFSWR, 
and  AIS  transponders  provide  close  to  continuous  reporting  of  position,  and  that 
OSWEX,  PAL,  and  DFO  sources  of  information  report  significantly  more  frequently 
than  others.  It  also  must  be  noted  that  the  DFO  info,  although  only  reported  every  12 
hours,  contains  position  information  at  10  minute  or  better  intervals. 
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Figure  3.  Vessel  detection  frequency 


4.3.5  Summary 

Table  4  shows  a  qualitative  analysis  of  the  criteria  outlined  above.  The  assessment  of 
each  criterion  is  based  on  “High/Med/Low”  ratings  (or  Unknown).  For  some  sources 
listed  there  is  missing  information  that  could  not  be  obtained  for  this  analysis. 

For  the  purpose  of  creating  a  valid  scenario  for  use  in  the  RTB,  the  criteria  are  not  of 
equal  importance.  It  is  more  important  that  the  source  of  information  capture  the 
greatest  percentage  of  the  maritime  traffic  (frequency/number  of  vessels)  and  that  the 
information  is  timely,  than  that  the  position  is  accurate  or  that  there  is  extensive 
information. 
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From  this  table,  it  can  be  seen  that  the  sensors  which  have  already  been  included  were 
good  choices  -  they  all  capture  a  large  percentage  of  the  total  maritime  traffic  with  a 
high  degree  of  timeliness.  To  continue  with  the  modeling  effort,  there  are  some  data 
sources  that  should  take  priority,  in  particular: 

AIS  should  be  attached  to  all  vessel  models  that  should  have  it,  and  all  AIS 

receivers  should  be  modeled.  AIS  captures  a  large  number  of  the  vessels  with 
easy-to-model  reporting.  It  is  also  anticipated  that  these  transponders  will  be 
increasingly  required  in  the  future,  and  therefore  could  be  expected  to  capture 
a  greater  percentage  of  the  maritime  traffic. 

The  PAL  flights  should  be  modeled,  as  this  gives  a  fairly  significant  capture 
percentage  with  good  timeliness  and  accuracy.  In  addition,  the  model  used 
for  PAL  would  be  easily  modified  to  represent  either  an  MPA  or  UAV. 

Other  data  sources  could  be  modeled  as  effort  is  available,  and  it  would  be 

valuable  to  answer  some  of  the  remaining  unknowns  about  new  information 
sources.  The  ability  to  track  maritime  traffic  by  satellite,  for  example,  could 
ensure  that  the  location  data  of  all  vessels  in  an  area  of  interest  is  completely 
accurate  and  timely,  although  another  means  of  providing  specific 
identification  would  be  required. 


Table  4.  Qualitative  analysis  of  the  entities’  characteristics 


VESSELS 

Frequency 

#  of  Vessels 

Accuracy 

Timelines 

Amt  of 
Info 

Modeling 

Difficulty 

OSWEX 

Med 

High 

Med 

High 

High 

Low 

CCG  INNAV 

Very  Low 

Highi 

Med 

High 

High 

Low 

MPA 

Low 

Low 

High 

Med 

High 

CF  Navy  own  ship 

High 

Low 

High 

High 

High 

Low 

Navy  reports 

Med 

Low 

High 

Low 

High 

Med 

PAL 

Med 

Med 

High 

High 

Med 

Med 

HFSWR 

High 

High 

Med 

High 

Low 

Med 

AIS 

High 

Med 

High 

High 

High 

Low 

ELINT 

UK 

Low 

Low 

UK 

UK 

High 

DFO 

High 

Low 

Med 

Low 

UK 

Low 

CCG  own  ship 

Low 

Low 

High 

Med 

High 

Low 

EO  Satellites 

UK 

High 

High 

High 

Low 

Low 

1  However,  a  ship  bound  for  port  may  not  be  in  the  Area  of  Interest  at  the  time  they  send  the  message. 
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UAV 

UK2 

Low 

High 

High 

Med 

Med 

ONI 

UK 

Low 

Med 

Low-Med 

UK 

Low 

TC  A/C 

UK 

Low 

High 

Med 

Med 

Med 

ECAREG 

UK 

UK 

UK 

UK 

UK 

Low 

4.4  Integration  of  Live  Data  Sources 

The  integration  of  live  data  into  the  RTB  simulation  was  mentioned  as  a  possible  need 
in  the  current  task.  This  was  never  subsequently  investigated  due  to  the  time  shortage; 
however,  the  following  paragraphs  provide  some  high-level  considerations  for  the 
potential  integration  of  live  data  sources.  If  it  is  later  determined  that  live  sources  are 
to  be  integrated,  the  feasibility,  cost,  and  effort  required  for  the  particular  data 
source(s)  would  have  to  be  determined. 

4.4.1  Integration  of  Live  Entities 

In  the  RTB  there  are  three  different  simulated  entity  types:  sensors,  sensor  platforms, 
and  targets,  where  “target”  refers  to  the  commercial,  fishing,  and  other  vessels  that 
make  up  maritime  traffic  in  an  area  of  interest.  To  create  the  Recognized  Maritime 
Picture,  there  must  be  a  realistic  representation  of  the  number  and  type  of  targets,  and 
of  the  number,  type,  and  capabilities  of  the  sensors  and  sensor  platforms.  Any  one  or 
all  of  the  three  entity  types  could  be  real  vessels  or  sensors  in  the  relevant  area  of 
interest. 

There  are  potential  advantages  to  involving  live  entities,  provided  that  the  entity  is 
integrated  into  the  simulation  with  minimum  data  latency  and  suitable  representation  to 
and  from  the  simulation  of  appropriate  information.  For  the  operator  of  a  sensor  or 
sensor  platform  (ship/aircraft),  integration  with  the  simulation  could  allow  them  to 
view  and  react  to  a  RMP  that  would  not  otherwise  exist,  with  specific  scenarios  to  test 
their  response  or  other  capabilities.  For  the  RTB  and  UAV  control  station,  live 
integration  could  allow  interaction  with  humans  to  perform  necessary  tasks. 

Integration  of  live  sensors  could  allow  accurate  sensor  results  without  considerations 
of  too-high  or  too-low  simulation  fidelity.  Integration  could  allow  direct  comparison 
of  the  performance  of  all  live  and  virtual  entities,  and  could  allow  participation  by 
virtual  operators  in  Ottawa  with  future  large-scale  live  exercises. 

There  are  very  significant  issues,  however,  with  attempting  to  integrate  live  sources 
over  long  distances,  as  would  be  the  case  with  the  RTB  in  Ottawa  and  the  live  entities 
off  the  east  coast.  An  issue  that  would  have  to  be  solved  before  any  others  could  be 


2  If  not  HIL  simulations,  could  represent  any  frequency  felt  to  be  realistic  in  a  future  context. 
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considered  is  that  of  communication.  It  would  be  necessary  to  have  information 
passed  between  airborne  and  shipbome  live  entities  and  the  RTB  with  latency  relative 
to  the  frequency  of  expected  update  of  the  entity  information.  For  example,  all  live 
sensor  platforms  and  targets  would  have  to  report  their  position.  This  has  been  done  in 
large  live/virtual  exercises  in  the  US  (Synthetic  Theatre  of  War  exercises,  for 
example),  so  it  is  certainly  possible  at  a  price. 

A  second  important  issue  is  ensuring  the  realism  of  interaction  at  both  ends  of  the 
long-distance  link:  if  a  live  sensor  platform  “sees”  a  target,  that  target  must  then  appear 
in  the  RMP  generated  in  Ottawa.  Trickier,  a  virtual  target  generated  in  the  RTB  must 
be  able  to  be  “acted  on”  by  a  sensor  platform  in  a  realistic  manner,  without  the  target 
actually  being  in  the  live  location  that  it  should  be  according  to  the  RMP. 

Any  decision  to  integrate  live  data  sources  would  need  to  be  made  considering  the 
potential  benefits  and  costs.  A  detailed  analysis  of  the  communications  methods, 
requirements  for  data  integration,  realism  issues,  and  the  like  must  be  performed. 
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5.  Lessons  Learned 


There  were  difficulties  encountered  during  the  development  of  the  synthetic 
environment.  We  believe  that  the  following  causes  contributed  significantly. 

5.1  Development  Environment 

The  development  environment,  i.e.  the  architecture  and  software  of  the  previous  ALIX 
configuration,  and  more  specifically  the  UAV  Research  Test  Bed,  was  not  favourable 
for  a  smooth  development.  It  was  assumed  that  building  from  the  current  configuration 
would  speed  development;  however  this  was  not  clearly  the  case.  Upgrading  the  main 
SE  software,  STRIVE,  to  STRIVE  2.0  from  STRIVE  1.8  was  deemed  to  be  too  costly 
for  the  present  project  alone.  Within  the  UAV  RTB  build  from  ALIX,  upgrading  a 
single  component  is  difficult  due  to  plug-ins  and  bridges  being  hard-coded  and  linked 
with  the  STRIVE  build.  As  a  result,  it  appears  that  upgrading  to  STRIVE  2.0  requires 
rewriting  the  code  for  the  STANAG  4586  plug-in,  the  OTH-Gold  plug-in,  and  re¬ 
integration  of  image  generators  and  video  streaming.  The  modified  STRIVE  toolset 
and  expired  licenses  also  caused  delays. 

We  note  also  that  the  current  system  has  two  different  configurations;  the  second, 
produced  by  CMC  Electronics,  was  not  familiar  to  the  contractor’s  developers. 

Existing  documentation  for  the  UAV  RTB  and  the  ALIX  SE  [14]  is  clearly 
insufficient.  Much  of  the  information  was  captured  [RTB  portal  website  reference], 
but  insufficient  for  to  capitalize  on  existing  development  as  a  starting  place. 

In  short,  the  current  development  environment  reflects  a  lack  of  knowledge 
management  and  process  infrastructure.  This  is  being  rectified  with  the  introduction  of 
formal  processes  for  development  and  documentation  that  will  lead  to  a  more  efficient 
development  environment;  among  other  we  can  cite:  Process  Benchmarking  and 
Business  Process  Improvement  (BPI)  [9]. 


5.1.1  Knowledge  Management 

According  to  Ocean  Literacy  “Knowledge  refers  to  what  one  knows  and  understands. 
Knowledge  is  sometimes  categorized  as  unstructured,  structured,  explicit  or  tacit.  What 
we  know  we  know  is  explicit  knowledge.  Knowledge  that  is  unstructured  and 
understood,  but  not  clearly  expressed  is  implicit  knowledge.  If  the  knowledge  is 
organized  and  easy  to  share  then  it  is  called  structured  knowledge.  To  convert  implicit 
knowledge  into  explicit  knowledge,  it  must  be  extracted  and  formatted.”  [13] 

Good  knowledge  management  within  an  organization  facilitates  communication  across 
projects,  increasing  information  sharing  and  utilizing  process  documentation.  This 
information  sharing  promotes  organizational  unity  and  allows  the  organization  to 
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function  efficiently.  The  truth  is  that  organizational  knowledge  and  best  practices  are 
found  in  only  one  place  within  the  organization,  i.e.  the  employee's  mind.  A  mind  set 
that  “knowledge  is  power”  for  the  employee  leads  to  implicit,  undocumented 
knowledge  that  is  at  risk  upon  the  loss  of  individual  employees.  On  the  other  hand, 
explicit  knowledge  can  be  shared  throughout  the  organization.  It  consists  of  the 
documented  experiences  of  those  who  have  performed  a  given  task. 

According  to  Burke  &  Howard,  the  traditional  “Progress”  is  first  data,  then 
information,  then  knowledge  and  finally,  wisdom  [7].  Data  alone  has  little  value  unless 
it  is  properly  structured  or  organized.  Once  appropriately  organized,  data  becomes 
more  useful  as  information.  Information  leads  to  knowledge  and  it  has  many 
definitions.  Wisdom  comes  from  the  ability  to  synthesize  various  streams  of 
knowledge,  enough  to  be  able  to  make  informed  judgments  about  various  ideas  and 
propositions  that  may  lie  outside  direct  areas  of  expertise. 

Consider  this  observation  made  by  Neil  Fleming  [6]  as  a  basis  for  thought  relating  to 
the  following  diagram. 

•  A  collection  of  data  is  not  information. 

•  A  collection  of  information  is  not  knowledge. 

•  A  collection  of  knowledge  is  not  wisdom. 

•  A  collection  of  wisdom  is  not  truth. 

The  idea  is  that  information,  knowledge,  and  wisdom  are  more  than  simply  collections. 
Rather,  the  whole  represents  more  than  the  sum  of  its  parts  and  has  a  synergy  of  its 
own,  as  shown  in  Figure  4. 
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Know 

dedge 

Figure  4.  The  Progress 


Knowledge  management  is  a  systematic  approach  to  facilitate  the  flow  of  data, 
information,  and  knowledge  to  the  right  people  at  the  right  time  so  they  can  act  more 
efficiently  and  effectively.  Knowledge  management  requires  an  organizational  effort  to 
build,  operate,  maintain,  and  proliferate  a  knowledge- sharing  environment.  To  create 
value  and  build  a  competitive  edge,  the  organization  needs  to  be  able  to  retrieve  and 
understand  the  structured  and  unstructured  data,  convert  data  into  useful  information, 
and  share  the  knowledge. 
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5,1.2  Process  Infrastructure 


A  capability  the  FFSE  is  lacking  for  the  efficient  development  of  a  synthetic 
environment  is  the  process  infrastructure.  While  it  is  true  that  much  of  the 
development  is  done  by  contractors,  the  crown  must  be  responsible  for  maintaining 
deliverable  code  and  systems,  and  putting  the  components  together  as  pieces  of  a 
puzzle.  Having  a  robust  process  development  will  help  prevent  projects  that  are  late, 
over  budget,  or  do  not  deliver  key  functionality. 

As  projects  continue  to  increase  in  size  and  importance,  these  problems  become 
magnified.  They  can  be  overcome  through  a  focused  and  sustained  effort  at  building  a 
process  infrastructure  of  effective  software  engineering  and  management  practices. 

To  build  such  process  infrastructure,  FFSE  must  assess  the  ability  to  perform  the 
software  process  successfully.  FFSE  also  needs  guidance  to  improve  the  process 
capability.  FFSE  need  ways  to  evaluate  more  effectively  the  capability  to  perform 
successfully  on  system  engineering  contracts. 

The  Capability  Maturity  Model  (CMM),  developed  by  the  Software  Engineering 
Institute  (SEI)  of  Carnegie  Mellon  University,  delineates  the  characteristics  of  a 
mature,  capable  software  process,  and  can  adequately  satisfy  this  need.  The  model 
describes,  in  terms  of  maturity  levels,  the  progression  from  an  immature,  unrepeatable 
software  process  to  a  mature,  well-managed  software  process.  CMM  is  sponsored  and 
used  by  the  DoD  and  the  National  Defense  Industrial  Association  (NDIA).  [12] 

Therefore,  it  is  recommended  that  FFSE  adopt  CMM,  by  applying  the  good  practices 
recommended  by  the  model  and  which  are  grouped  in  the  following  5  levels  of 
maturity: 

•  Initial:  the  processes  are  ad  hoc  and  chaotic.  The  factors  of  success  of  the 
projects  are  not  identified;  thus  the  success  cannot  be  repeated. 

•  Repeatable:  projects  are  controlled  individually. 

•  Defined:  the  processes  of  piloting  the  projects  are  set  up  at  the  organizational 
level.  The  processes  are  well  characterized  and  understood,  and  are  described 
in  standards,  procedures,  tools,  and  methods. 

•  Managed:  the  success  of  the  projects  is  quantified.  The  causes  of  variation  can 
be  analyzed. 

•  Optimized:  the  step  of  optimization  is  continuous.  Maturity  level  5  focuses  on 
continually  improving  process  performance  through  both  incremental  and 
innovative  technological  improvements.  [12] 

It  could  be  argued  that  FFSE  is  currently  at  the  level  of  Repeatable  execution 
processes,  because  identical  data  sets  can  be  produced  through  re-use  of  previous 
experimental  set-ups.  The  authors  highly  recommend  progressing  within  the  maturity 
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categorizations,  not  simply  by  awaiting  maturity  of  the  organization  and  surrounding 
simulation  partners,  but  by  actively  initiating,  employing  and  documenting  the 
processes  surrounding  an  experiment  in  FFSE. 


5.2  Team  Roles  for  the  SE  Development 

There  was  some  confusion  in  the  roles  of  the  FFSE  and  RAST  staff  For  this  project 
and  likely  for  future  projects,  the  FFSE  section  has  the  role  of  project  sponsor  and  is 
responsible  for  the  SE  across  multiple  projects.  The  RAST  section  was  the 
stakeholder;  in  the  future  the  CF  may  take  this  role  directly  as  the  client.  However, 
these  roles  emerged  during  this  project  and  were  not  clearly  defined  at  the  outset  or 
during  the  whole  lifecycle  of  the  project. 

The  contractor,  Greenley  &  Associates  Inc.,  [8]  defines  itself  as  a  consulting  service 
provider  that  offers  clients  expertise  in  the  core  service  areas  of  modeling  and 
simulation,  project  management  human  factors,  business  analysis  and  usability,  and 
emergency  management. 

In  a  multi  project  environment,  like  that  employed  by  Greenley  &  Associates,  where 
personnel  are  shared  across  a  number  of  different  projects,  the  list  of  tasks  for  both 
individual  employees  and  projects  can  be  lengthy.  Such  an  environment,  typically, 
generates  many  priorities  for  project  resources  and  managers  alike  and  can  make  focus 
difficult  to  achieve.  In  such  situations,  dedicating  resources  to  projects  might  waste 
them  by  making  them  unavailable  to  support  other  more  important  projects. 

5.3  Project  Management 

The  project  manager  is  the  catalyst  for  the  good  progress  of  the  project  and  the  detector 
of  potential  problems  which  would  cause  slippage  in  the  project  schedule. 

The  project  manager  is  the  link  between  the  client  and  the  contractor  team  and  this  link 
was  lacking  in  this  project.  Here,  the  situation  was  that  a  junior  developer  was 
required  to  manage  the  relationship  and  information  flow  with  a  sub-contractor  (in  this 
case,  CAE  Inc.),  and  communicate  the  situation  to  the  stakeholder  in  the  RAST 
section. 

We  believe  that  clear  communication  is  necessary  between  all  parties  and  it  is  the 
responsibility  of  the  program  manager  to  make  the  program  understood  and  accepted 
by  all. 

It  also  appears  that  the  difficulty  of  the  task  was  underestimated  by  both  the  contractor 
and  the  FFSE  section.  This  may  be  a  result  of  an  overestimate  of  the  capacity  of  the 
tool  i.e.  CAE-STRIVE. 

Risk  mitigation  should  proactively  target  risk  drivers.  Structured  effectively,  a  risk 
mitigation  program  should  prevent  loss  and  reduce  the  repercussion  of  losses  that  do 
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occur.  During  the  planning  stage,  the  contribution  of  a  senior  software  engineer  was 
envisioned,  scoped  and  budgeted.  During  the  execution  of  the  entire  project,  no  senior 
software  engineer  was  involved.  The  bulk  of  the  work  was  made  the  responsibility  of  a 
junior  Software  Engineer  We  assume  that  this  was  due  to  stretching  of  resources 
within  the  contractor’s  organization  which  can  at  times  be  unavoidable  due  to 
instability  or  volatility  in  the  industry.  But  what  must  be  highlight  here  is  that  nothing 
was  done,  from  the  program  management  point  of  view,  to  mitigate  this  loss. 
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6.  Conclusions  and  Future  Work 


The  benefits  of  an  SE  approach  as  a  component  of  programs  for  experimentation  and 
capability  development  are  clear  in  terms  of  scalability,  cost  effectiveness  and 
practicality.  SEs  also  offer  the  opportunities  for  operators  to  gain  experience  in 
operations,  and  training  before  new  equipment  is  fully  available,  or  for  large  numbers 
of  staff  for  whom  sufficient  equipment  could  not  be  made  available.  This  is  in  line 
with  the  DRDC  thrust  description  (see 

http://admmatapp.dnd.ca/cosmat/dmasp/downloads/ModellingSimulation/) 

The  present  task  showed  that  even  with  low  fidelity  models,  an  SE  we  can  be  produced 
that  is  suitable  for  evaluating  the  challenge  experienced  by  operations  teams  to  fuse  all 
the  data  for  Recognized  Maritime  Picture  (RMP)  generation. 

The  range  of  missions,  for  maritime  ISR  in  particular,  that  can  be  executed  in  a 
synthetic  environment  is  growing  more  expansive  and  synthetic  environment  are 
becoming  increasingly  important  for  analysis  of  C2/C4ISR  systems.  An  SE  Mission 
Rehearsal  and  Training  documents  the  shortcomings  with  systems  as  well  as  the 
requirements  of  the  future  systems,  and  addresses  the  ability  to  integrate  different 
models  with  regard  to  forces,  infrastructures,  tactics,  techniques  and  procedures. 

The  present  task  also  revealed  several  lacunas  that  are  gathered  in  the  lessons  learned 
section.  Some  of  these  can  be  significant,  especially  as  the  FFSE  section  grows  in 
terms  of  variety  of  the  projects  it  tackles.  The  two  most  critical  issues  are  the  lack  of 
knowledge  management  and  the  lack  of  process  infrastructure. 

To  offer  better  support  for  future  Maritime  Traffic  Simulation  trials,  future 
development  must  include: 

•  The  continued  development  of  entity  models  and  sensor  models  to  complete 
the  maritime  environment  and  the  continued  improvement  to  the  current  set  of 
models.  Along  with  the  resolution  of  the  fidelity  issues. 

•  The  exploration  of  decoupling  the  developed  entity  and  sensor  models  from 
the  simulation  toolset  by  designing  these  models  as  standalone  federates. 

•  The  investigation  of  other  simulation  toolsets:  some  difficulty  was  found  with 
the  current  simulation  tool,  i.e.  CAE-STRIVE  [12],  and  to  maintain  a  vibrant, 
competitive  industry  of  providers,  as  well  as  ensure  a  suitable  selection  of 
tools,  other  tools  must  be  investigated.  This  is  being  pursued  in  a  current 
project  within  the  FFSE  section  on  SE  tool  analysis 
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Appendix  A  -  Maritime  Traffic  Fishing  Dataset 


FFSE  106  FISH  Difla  Final. *1* 
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44  176795 

-49  516888 

2  9 

069  3T 

77 

UN EQUATED 

ONTIKA 

FISH 

MER 

AAt 

EN 

N415D4 

CL1N461 225957 

E-5KO 

s/29/12  oo.do 

44  541603 

-53  324C44 

4.1 

201  AT 

76 

UN EQUATED 

TAURUS 

FISH 

MER 

AAI 

EN 

M6415S 

CMN461 2  3£D'  5 

ESFO 

3/20/12  oo.do 

44.174177 

-52.930051 

3.5 

053  2T 

84 

UN EQUATED 

VIAQRUS 

FISH 

MER 

AAt 

EN 

MG  44  $4 

CMN461237545 

ESQO 

SI29Q6  25  00 

46690577 

-52  350871 

3.3 

130  2T 

144 

UN EQUATED 

ELDBORG 

FISH 

MER 

AAI 

EN 

N 252 36 

CMN461237546 

ESPY 

3/29/0&  zft:oo 

44  156102 

-52.110117 

4 

067.9T 

152 

UNEQUATED 

ANOVARI 

FISH 

MER 

AAI 

EN 

CMN  401237 547 

ESPD 

8/29/07:02:00 

50086307 

■52.085428 

3  8 

000  4T 

IS 

UN EQUATED 

HQGIFOSSUR 

FISH 

MER 

AAI 

FO 

M84Q53 

CMN401238147 

OW234S 

a/29C3  22  00 

47032818 

■51.88255 

5.1 

000  AT 

130 

UN  EQUATED 

SOLBURG 

FISH 

MER 

AAI 

FO 

M04138 

CMN461224B02 

TFFT 

3/29/03  54  DO 

43.23956 

-51.4BB123 

3.8 

296.4T 

30 

UN EQUATED 

ENW6ERG 

FISH 

MER 

AAI 

FO 

M 10806 

CMN4012341O2 

XPXL 

S/2912  34  00 

43  987191 

-50.75361 

2.1 

0S3T 

13 

UN EQUATED 

CSO  MARIANOS 

FISH 

MER 

AAI 

BF 

M35S12 

CMN462456365 

C6L03 

S/29/T2  45.00 

44  394603 

-49.879453 

3.7 

051  .JT 

132 

UN EQUATED 

POLA  R  SIG  UR 

FISH 

MER 

AAI 

&L 

M43227 

CMN  481263040 

OZPL 

8/2904  44:00 

40  642902 

-51  43393 

38 

193.8T 

22 

UN EQUATED 

ZUIHO  MARO  NOfie 

FISH 

MER 

AAI 

JA 

N50397 

CMN 401237545 

JMSA 

8/2912  00:00 

49.21 1220 

-53  3595G 

2.3 

112. IT 

7 

UN EQUATE 3 

TENOR 

FISH 

MER 

AAI 

NO 

M07B65 

CMN4612427B3 

LALU 

3/2907. 51  :D0 

45  905435 

-52.07594 

0.9 

000.4T 

186 

UN EQUATED 

SAEWKING 

FISH 

MER 

AAI 

NO 

M08263 

CMN4012379S9 

LLNF 

8/2907  32:00 

43  807822 

■52.0(7248 

2.1 

048.  IT 

17 

UN EQUATED 

ARCTIGSWAN 

FISH 

MER 

AAI 

NO 

M08213 

CMN461237549 

LMAC 

8/2905  43:00 

50  287678 

■52.005793 

3.1 

039  2T 

57 

UN  EQUATED 

ATLANTICSTAR 

FISH 

MER 

AAt 

NO 

CMN462456BB0 

LMBG 

3/2904. 23. DO 

44  136566 

-51  349662 

4.1 

112. IT 

65 

UN EQUATED 

VESTTlND 

FISH 

MER 
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NO 

CUN4A-237&&1 

LMCX 

8/2907  46:00 

44061513 

-51.312085 

2.2 

000.4T 

137 
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CA 
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0.2 

000.4T 

84 
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MER 
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FIS 
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CMN461337567 

UHLW 
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49  539009 

-51.204421 

4  4 

O004T 

16 

UN EQUATED 

GEMENY 
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MER 
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RS 

CMN401237S72 

UIXH 

8/2902  54:00 

44.36317 

-50.909523 

2.1 

0Q0.4T 

140 
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AROUND  THE  CLOCK 

FISH 

MER 

AAt 

RS 

MS6M3 

CMN401237567 

UHLW 

a/29/12  46:00 

47  2346 

-4ft  3564 

3j0 

049. ST 

iaa 
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PATRICIA  SOTELO 

FISH 

MER 

AAI 

SP 

N71BD1 

CMN461 237531 

EAVX 

3/2912  DODO 

45  501943 

-49.3554 

6.1 

040  2T 

162 

UN EQUATED 

PLAYA  DE  ARKELES 

FISH 

MER 

AAI 

SP 

CMN401237S32 

ESWJ 

3/29/1200:00 

47  1 77267 

-50.622242 

3.8 

2fi6.4T 

150 

UN EQUATED 

ElftADO  DO  COSTAL 

FISH 

MER 

AAI 

SP 

CMN40245622O 

EGKW 

8/291200:00 

44  498575 

-50.581212 

2.1 

268. 4T 

36 

UN EQUATED 

PLAYA  PE  UENPUINA 

FISH 

MER 

AAI 

SP 

CMN  452465701 

6EKN 

8/2912- 00.00 

43  324543 

-50.576372 

3.7 

314. 0T 

00 

UN EQUATED 

MANUEL  ANGEL  NOftES 

FISH 

MER 

AAI 

SP 

MS7130 

CMN461 23633 

EAMC 

3/2912  00:00 

47002609 

-50.48ftft41 

0.8 

067 ,0T 

43 

UN EQUATED 

MORADINA 

FISH 

MER 

AAI 

SP 

N3/B27 

CMN 401237534 

EDQR 

62912  00:00 

46  75745# 

-50.190701 

2.3 

149.3T 

7B 

UN EQUATED 

SANTA  MARINA 

FISH 

MER 

AAI  I 

SP 

N4W93 

CMN  461237 536 

EEMX 

S/2912  00  00 

4509Q233 

■49  991838 

3v9 

055  3T 

56 

UN EQUATED 

COD  ESI  DE 

FISH 

MER 

AAI 

SP 

N 32365 

CMN461237543 

EHU2 

9291200:00 

49922356 

-49.93565 3 

2.1 

000.4T 

13 

UN EQUATED 

BUSSOL 

FISH 

MER 

- 

RS 

M33672 

CMN462466773 

UCT2 

3/291200:00 

44  2342 

-49.625 

2.1 

296.4T 

140 

UN EQUATED 

ATLANTIC  PEACE 

FISH 

MER 

- 

GM 

M0 5907 

CMN 461237946 

□EOT 

S/2912  00  00 

47  393092 

‘49  685502 

38 

0C0  4T 

54 

UN EQUATED 

NEWFOUNDLAND  OTTER 

FISH 

MER 

* 

CA 

M1217& 

CMN401230028 

CF0365 

8/29/ >2  00:00 

44.1037 

-49.31 

5.1 

000.4T 

136 

UN EQUATED 

GERDA  MARIA 

FISH 

MER 

- 

GM 

Ml  1321 

CMN46124664Q 

DFLM 

3/2912  DO  00 

46  085563 

-49.456364 

0.8 

000.4T 

61 

UN EQUATED 

STRAIT  FALCON 

FISH 

MER 

- 

CA 

M541G2 

CMN 461249037 

HP9417 

S/29/12  00:00 

48  454511 

-49.059975 

2.1 

060  2T 

2 

UN EQUATED 

PESO ABE R&ES 

FISH 

MER 

- 

SP 

M06935 

CMN401226056 

EHXX 

3/291200:00 

40  203914 

-48.340597 

3.7 

149.3T 

139 

UN EQUATED 

COVA 

FISH 

MER 

- 

SP 

M51966 

CMN461237537 

EGBP 

3/291200:00 

44  666343 

-46.422274 

2.3 

000.4T 

151 

UN EQUATED 

Q2ERNITSA 

FISH 

MER 

- 

RS 

MS  7564 

CMH461252952 

UIDS 

3/29/12  00:00 

46671371 

-48.121467 

0.9 

296.4T 
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Appendix  C  -  Maritime  Traffic  Other  Dataset 


FF$E  106  OTHER  FinalUls 


HITT  ID 

Class 

Name 

Type 

Category 

QSWEX 

AIS  1 

Flag 

SCONUM 

UID 

Radio  Cal 

Dale-Time 

Lat 

Long 

Speed 

38 

UN EQUATED 

AMUNDSEN 

AGB 

NAV 

OSWEX 

CA 

N543S8 

CMM461 237508 

CGDT 

8/29/15.00  0Q 

47.073 

-49471 

8. 00 

6/20/19:17:00 

46.234 

-43.271 

13.00 

8/30718:34:00 

46.123 

■68.170 

14.00 

mm&s&oo 

54.026 

-54.160 

10.00 

39 

UN EQUATED 

MARTHA  M  BLACK 

AGB 

NAV 

Q5VYEX 

CA. 

M07547 

CM  N461 23656 

CGCC 

8/29712:16:00 

44.883 

-52.071 

12.90 

20:23:00 

46.603 

-52.476 

13.03 

8/30704:00:00 

47956 

-50.958 

13  02 

6/30/14:5000 

40.405 

-47.874 

13.71 

8/30722:48:00 

50.00S 

-4S.324 

14.40 

78 

UN EQUATED 

ATHABASKAM 

DUG 

NAV 

OSV7EX 

CA 

A6508S 

CMN461 237593 

CYVWI 

• 

41.930 

-56.268 

14.21 

8/29722:41:00 

42.426 

■53.656 

11.56 

8/30715:2900 

43.066 

-49.006 

12  69 

8/30/23: 1 7  00 

43.336 

-46.637 

11,72 

UN EQUATED 

RV  ENDEAVOR 

AGE 

MER 

CA 

M62714 

CMN461 250831 

SKOZ 

fi/23710  2-v  C  j 

45.230 

-51  107 

10.00 

8/29713:19.00 

46.240 

-46.450 

1200 

6/20/18:55:00 

44.231 

-52226 

12.00 

UN EQUATED 

CABOT  SEA 

AGE 

MER 

CA 

N37044 

CMN  401237 523 

CFDB024 

8/29708:00:00 

47.300 

53.000 

15.00 

3/30718:05  00 

-40.420 

-58.341 

14.00 

UN EQUATED 

CHARLES  DARWIN 

AGE 

MER 

CA 

M 54 102 

CMN461 249007 

GDLS 

8/29711:34:00 

47.013 

-60.201 

15.00 

3/23718:40:00 

42.275 

-62451 

12.00 

3/30/18:37:00 

49.100 

-70.460 

11.00 

S3 

UN EQUATED 

BARBARA  JEAN 

YAC 

MER 

CJ 

CMM4B2450792 

ZCGA2 

8/29712:00  00 

50834295 

-48  461585 

3.80 

137 

UN EQUATED 

PORT  MECHINS 

TMD 

MER 

PM 

M54102 

CMN462456T92 

VGVvN 

6/20/12:0900 

45.4313 

-49.S827 

4.40 
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Appendix  D  -  STRIVE:  SE  Development  Tool 


Overview 

In  a  nutshell,  CAE  STRIVE  is  a  Commercial  Off  The  Shelf  (COTS)  simulation 
development  tool  and  mainly  composed  of  two  parts: 

•  STRIVE  framework  suite  (AFX)  is  a  Modeling  and  Simulation  framework 
tool  that  gives  software  developers  the  ability  to  design  complex  interoperable 
systems. 

•  STRIVE  CGF  is  a  high  fidelity  full  function  synthetic,  tactical  environment 
and  computer  generated  forces.  It  is  a  software  product  that  simulates  a  real¬ 
time  virtual  battlefield  for  air,  land,  sea,  and  space  applications. 

The  available  version  for  FFSE,  is  STRIVE  1.8  beta  version. 

Customers  can  also  add  capabilities  for  specific  needs  such  as  radar,  electro-optic, 
communications  or  weather. 

Because  STRIVE  is  a  PC  based  and  HLA  compliant,  systems  and  subsystems  can  be 
linked  together  as  needed  for  a  “plug-and-play”  environment  [1]. 
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Figure  5.  STRIVE  Screen  Snapshot 


Usage  of  STRIVE  in  FFSE 

Typically,  a  company  or  an  organization  will  use  STRIVE  as  a  technological  enabler 
to  support  all  phases  of  a  project’s  life,  including  research,  analysis  and  acquisition. 
The  FFSE  section  at  DRDC  Ottawa  is  a  major  user  of  STRIVE.  Within  FFSE, 
STRIVE  is  used  for  the  evaluation  of  the  potential  of  Unmanned  Aerial  Vehicles 
(UAV)  and  for  the  development  of  an  expertise  that  would  allow  it  to  purchase  UAVs. 
Another  usage  for  STRIVE  is  the  providing  of  a  rehearsal  and  a  set  of  complementary 
experiments  in  a  synthetic  environment  for  the  Atlantic  Littoral  Intelligence 
Surveillance  Reconnaissance  Experiment  (ALIX).  The  overall  outcome  for  the 
rehearsal  event  was  a  demonstration  of  the  potential  for  experimentation  in  synthetic 
environments.  The  experiment  did  not  provide  accurate  predictions  of  quantitative 
measure  compared  to  similar  live  experiments,  because  the  entity  models  were  not 
calibrated,  (i.e.  validated). 

For  more  information,  please  see  the  DRDC  technical  note  on  this  topic  [12]. 
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Appendix  E  -  Installation  Instructions 


Create  a  copy  of  the  existing  STRIVE  installation  directory,  as  following  these 
instructions  involves  reinstalling  STRIVE.  All  data  in  the  current  STRIVE 
directory  will  be  lost. 

Set  the  environment  variables  as  shown  in  Table  5: 


Table  5.  Environment  Variables 


ENVIRONMENT  VARIABLE 

PURPOSE 

GCCSIP 

IP  Address  of  the  GCCS  Computer. 

GCCSPort 

Port  on  which  to  receive  OTH-GOLD  messages. 

CGF_DYNAMICS_SUBBANDING_LEVEL 

1 

CG  F_SH  1  P_D  YN  AM  1  CS_S  U  BBAN  D 1 N  G_LEVEL 

5 

16.  Copy  the  LatestChange  directory  from  the  CD  overtop  the  existing  STRIVE 
installation.  Hit  OK  when  prompted  to  overwrite  existing  files. 

17.  Open  UAV  SHELL  and  run  the  UAV_3_PostProcess_Specimens_phase3.bat 
file  found  in  the  script  directory  of  the  STRIVE  install. 

18.  Open  STRIVE  Studio,  Click  File  ->  Import,  and  import  the  following  files: 
An  AA1  Report.sfx 

An  AA1-AIS  Report.sfx 
An  AIS  Report.sfx 
An  HFSWR  Report.sfx 
An  OSWEX  Report.sfx 
blank,  sfx 
Figure8_2KM.sfx 

19.  Open  the  blank  scenario  in  Strive  Studio  and  set  the  exercise  Host  and 
Participant  Host  to  the  local  machine  in  the  exercise  properties  panel. 
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20.  Save  the  scenario  and  Exit  Strive. 

21 .  Open  UAV  SHELL  and  run  gen.bat  from  the  CD.  This  will  create  the  fish 
and  merch  scenarios.  One  error  will  be  generated  -  this  is  the  normal 
behaviour. 
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Appendix  F  -  STRIVE  Doctrines 


Doctrine:  An  Oth  Weather  Report 

Rule  Base:  Rule  Base  1 

Rule1  Set:  Rule  Set  I 


1 . 1  IF  Variable  LantlYR  is  .assigned  ~  FAI/SK 

THEN  Set  Variable  LastWR  -  1 1 

1 .2  IF  N  umber  of  seconds  since  scenario  stall  LastWR 

THEN  Set  Variable  LastWR  ~  (Number  of  seconds  since  scenario  start  h  603 

THEN  Execute  Response 

Category  Communication 
Type:  Send  Weather  Report 

Parameters:  Casting  Method  =  Broadcast 
Message  Format  -  GthGold 
Transmitter  Type  =  RealGccs  Communications 
Network  to  Use  -  Current  Network 


1 3  Execute  Response 

Category:  C  ommun  icati  on 

Type:  Send  Tactical  Message 

Parameters:  (  listing  Method  =  Broadcast 

Tactical  Message  to  Send  =  I  am  in  Position 
Message  Format  =  Plain 

Transmitter  Ty  pe  =  Basic  Communications 

Network  to  Use  =  Current  Network 
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Doctrine:  Figure8_2KM 


Rule  Base:  Rule  Base  1 

Rule  Set:  Rule  Set  I 

LI  S et  Variabl e  A  hixDi  stance  2 000 
Set  Variable  MinDi&t&nce  =  500 

1.2  IF  (  Vari abl t  Ini t  is  assigned  ~  T R U  E  AN D 

Hegding.4  wayFraniStart  FALSE  ) 

THEN  Invoke  Rule  Set  KeepGomg 

1.3  IF  (  Variable  I  nit  is  assigned  TRUE  AND 

Heading  A  waiFromStart  ~  TRUE  ) 

THEN  Invoke  Rule  Set  TumAhoutRiile 

L4  IF  Variable  ini  Ms  assigned  FALSE 

THEN  Set  Variable  StartLocation  -  Location  of  Self  Entity 
THEN  Set  Variable  I  nil  ~  TRUE 
THEN  Execute  Response 


Category:  Navigation 
Type:  Navigate 


Parameters:  Heading  Mode  -  Unchanged 


Velocity  mode  =  Absolute 

Requested  velocity  =  2.06 

Indicated  airspeed  ~  FALSE 

Navigation  mode  =  Contour 

Requested  altitude  (asl)  ~  0 


THEN  Set  V ■  ar mb le  / 1 eadi ngA  vr HromStart  TRUE 


2,1  IF  Slant  Range  from  Self  Entity  to  StartLocation  < ~  MinDi stance 
THEN  Execute  Response 


Category:  Navigat  ion 
Type:  Navigate 


Parameters  :  Heading  Mode 


-  Unchanged 
=  Absolute 


Velocity  mode 
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Requested  velocity  =2.06 

Indicated  airspeed  =  FALSE 

Navigation  mode  =  Contour 

Requested  altitude  (asl)  0 


THEN  Set  Variable  Headin^AwavFrofiiSiart  ~  TRUE 

Rule  Set:  TiimAboutRule 

3.1  1 F  Ground  Range  fi  om  Self  Entity  to  SlarfLocation  >  MaxDi stance 

THEN  Execute  Response 

Category:  Navigation 


Type:  Navigate 


Parameters:  Heading  Mode 

Requested  heading 


=  WRT I  vocation 
=  0.000000000000000ei-000 


Requested  location  (coordinates)  -  SiartLocation 


Velocity  mode 
Navigation  mode 
Requested  altitude  (asl) 


Unchanged 
=  Contour 
=  0 


THEN  Set  Variable  HeadingA™ avFromStan  ~  FALSE 
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Doctrine:  An  AA1  Report 

Rule  Base:  Rule  Base  1 

Rule  Set:  Rule  Set  1 


LI  ]  F  Variable  Last  Report  is  assigned  -  FALSE. 

THEN  Set  Variable  LastReport  -  0 

1.2  IF  Number  of  seconds  since  scenario  stall  LastReport 

TIIFN  Execute  Response 

Category:  Communication 
Type:  Send  AA1  Report 

Parameters;  Casting  Method  Broadcast 
Situation  to  Report  -*  Self  Entity 
Message  Format  =  OthGoId 
Transmitter  Type  -  RealGces  Communications 
Network  to  Use  =  Current  Network 

THEN  Set  Variable  LastReport  z  ( Number  of  seconds  since  scenario  start  ■  60) 

1.3  Execute  Response 

Category:  C  omm  un  ical  ion 

Type:  Send  Tactical  Message 

Parameters:  Casting  Method  —  Broadcast 

Tactical  Message  to  Send  =  I  am  in  Position 
Message  Form  at  -  Plain 

Transmitter  Type  Basic  Communications 

Network  to  Use  -  Current  Network 
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Doctrine:  An  AIS  Report 

Rule  Base:  Rule  Base  1 

Rule  Set:  Rule  Set  I 


1.1  IF  Variable  Last  Report  is  assigned  =  FALSE 
THEN  Set  Variable  LastRej?ort  ~  0 

1-2  IF  Number  of  seconds  since  scenario  start  >  LasiHepori 

THEN  Execute  Response 

Category:  Communication 
Type:  Send  AIS  Report 

Parameters:  Casting  Method  -Broadcast 

Situation  to  Repo  it  -  Self  Entity 
Message  Format  =  OthGold 
T ra nsin itter  Type  -Re alGces  C omimmi cati on s 
Network  to  Use  =  Current  Network 

T H EN  Sd  Variable  LgstRegort  =  ( Number  of  seconds  since  scenario  .start  + , 60) 


1 3  Execute  Response 

Category’ :  C  ommun  icati  on 

Type:  Send  Tactical  Message 

Parameters:  Casting  Method  =  Broadcast 

Tactical  Message  to  Send  I  am  in  Position 
Message  Format  =  Plain 

Transmitter  Type  Basie  Communications 

Network  to  Use  -  Current  Network 
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Doctrine:  An  AA1-AIS  Report 

Rule  Base:  Rule  Base  1 

Rule  Set:  Rule  Set  I 


I  t  IF  Variable  LastAis  is  assigned  FALSE 

THEN  Set  Variable  LastAis  -  1 

THEN  Set  Variable  LastAa I  -  3 

1 .  2  IF  Number  of  seconds  since  scenario  start  LastAa! 

THEN  Execute  Response 

Category:  Communication 
Type:  Send  AAt  Report 

Parameters:  C  ii^t in s  Method  -  Broadcast 
Situation  to  Report  -  Self  Entity 
Message  Format  =  OthGold 
Tmnsinitter  Type  RealGccs  Communications 
Network  to  Use  -  Current  Network 

THEN  Set  Variable  LastAa  1  -  (Number  of  seconds  since  scenario  stall  +  46) 

13  IF  Nu  m  be  r  of  sec  o  n  ds  s  i  n  ce  s  een  ari  o  stall  >  Last  A  is 

THEN  Execute  Response 

Category:  Communication 
Type:  Send  AIS  Report 

Parameters:  Casting  Method  =  Broadcast 
Situation  to  Rep  oil  -  Self  Entity 
Message  Format  =  OthGold 
T ra nsm iff er  Type  -Re alGccs  C ommuni cati on s 
Network,  to  Use  —  Current  Network 

THEN  Set  Variable  LastA  is  ~  (Number  of  seconds  since  scenario  start  t  37) 

1  4  Execute  Response 

Category:  Communication 

Type:  Send  Tactical  Message 

Mmm trn-  Casting  Method  =  Broadcast 

Tactical  Message  to  Send  =  I  am  in  Position 
Message  Format  =  Plain 

Transmitter  Type  =  Basic  Communications 

Network  to  Use  =  Current  Network 
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Doctrine:  An  HFSWR  Report 

Rule  Base:  Rule  Base  1 

Rule  Set:  Rule  Set  1 


1 . 1  IK  Variable  LaslReport  is  assigned  =  FALSE 

THEN  Set  Variable  LastReport  -  G 
THEN  Execute  Response 
Category:  Radar 
Type:  Set  Radar  Mode 

Parameters:  Radar  Mode  for  all  radars  -  Search 


1.2  IF  N  umber  of  seconds  s  inee  scorer i  o  start  >  Las  (Report 

THEN  Execute  Response 

Category:  Communicati  on 
Type:  Send  HFSWR  Report 

Parameters :  Casting  Method  -  Broadcast 
Contact  to  Report  =  Self  Entity 
Message  Fomiat  OtfaGold 
Transmitter  Type  _  RealGccs  Communications 
Network  to  Use  —  Current  Network 

THEN  Set  Variable  LaslR&porl  -  fNumher  of  seconds  since  scenario  start  -  60 1 

1.3  Execute  Response 

Category:  Communication 

Type:  Send  Tactical  Message 

Pararneters:  Casting  Method  -  Broadcast 

Tactical  Message  to  Send  =  I  am  in  Position 
Message  Fomiat  =  Plain 

T ransm itter  Type  =  Basic  Communications 

Network  to  Use  ~  Current  Network 
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Appendix  G  -  High  Frequency  Surface  Wave 
Radar  (HFSWR) 


Because  of  the  curvature  of  the  earth,  and  the  line  of  sight  target  detection  for  radars, 
low-altitude  and  surface  targets  are  not  detected  by  microwave  radars.  High-frequency 
surface  wave  radar  (HFSWR)  is  a  technology  that  is  overcoming  this  limitation. 
Surface  waves  propagate  efficiently  for  vertical  polarization  over  a  conducting  surface. 
Consequently,  over-the-horizon  application  of  HFSWR  is  practical  for  coastal  or 
shipboard  installations  where  the  ocean  surface  serves  as  the  conductor.  The  Canadian 
HFSWR  technology  has  been  developed  through  the  combined  effort  of  scientists  and 
engineers  of  DRDC  Ottawa  and  Raytheon  Canada  Limited  (RCL)  [10]. 

In  2003  Canada  announced  the  maritime  security  initiatives.  There  is  a  provision  of  a 
$45  M  funding  to  procure  a  network  of  HFSWR  that  oversees  the  east  and  west  coasts. 
On  the  east  coast,  DND  has  built  two  High  Frequency  Surface  Wave  Radar  (HFSWR) 
sites  that  can  track  vessels  of  3000  tons  or  more  as  far  as  170  miles  off  the  coast.  One 
was  installed  at  Cape  Bonavista,  the  other  at  Cape  Race,  Newfoundland  see  Figure  6. 
This  technology  is  seen  as  being  at  the  forefront  for  future  surveillance  and  tracking  in 
Canadian  off-shore  waters,  especially  for  tracking  vessels  which  do  not  comply  with 
other  automatic  tracking  systems.  The  two  radar  facilities  in  Newfoundland  provide  an 
ideal  proving  ground  for  further  refinements  to  the  radar  and  a  place  to  showcase  the 
technology  to  potential  customers  [10]. 

The  Navy  considers  the  HFSWR's  potential  as  very  positive  for  enhancing  the 
Recognized  Maritime  Picture  (RMP)  and  common  operating  picture  (COP), 
surveillance  tools  for  the  Canadian  Forces  (CF).  The  HFSWR  provides  information  on 
low-altitude  and  surface  targets  within  its  surveillance  area  on  a  real-time  basis.  Tracks 
of  detected  targets  will  be  sent  to  the  Operation  and  Control  Centre  (OCC)  from  the 
radar  sites  via  communication  links.  Besides  providing  tracks  of  vessels,  icebergs  and 
aircraft,  the  radar  data  is  processed  to  extract  information  regarding  the  conditions  of 
the  ocean  surface,  for  example,  the  height  and  direction  of  waves.  The  introduction  of 
this  new  sensor  promises  to  provide  more  timely  surveillance  data  to  Maritime 
Command.  The  continuous  surveillance  data  provided  by  the  HFSWR  make  it  possible 
to  associate  contacts  from  dissimilar  sensors  and  form  composite  tracks.  This  enhances 
Maritime  Command's  ability  to  manage  and  exploit  raw  sensor  data  [10]. 
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Figure  6.  HFSWR  Coverage 


HFSWR  MODEL  SWR-1018  [9] 


Implementation 


Complete  radar  system  is  delivered  factory-installed  in  ISO 
shelter 


Configuration 

Frequency  Band 
AC  Supply 
Power 

Consumption 

Transmitter 


Redundant  receiver  exciter  signal  data  processors  operating 
on  interleaved  dual  frequencies  with  a  shared  fail-soft 
transmitter  power  amplified 

10  to  18  MHz 

1 15  to  230  V  60  Hz  single  phase 

22  kVA  (radar  equipment  operating)  36  kVA  (radar 
equipment  plus  air  conditioning  for  peak  load  on  hottest 
day) 

8  kW  peak,  0.8  kW  average 
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Power 

Occupied 

Bandwidth 

3  to  80  kHz  determined  by  available  spectrum;  typically 
operates  at  less  than  20  kHz 

Waveform 

Stepped  FM/phase 

Transmit 

Antenna 

Monopole  log  periodic 

Receive  Antenna 

16-element  monopole  array  on  groundscreen 

Update  Rate 

165  seconds  typical 

Doppler 

Resolution 

0.01  Hz  typical 

Azimuth 

Resolution 

6  degrees  nominal;  two  targets  will  be  resolved  provided 
they  are  distinguishable  in  any  one  dimension 

Range 

Resolution 

4  nm  nominal  at  20  kHz  BW 

Track  Accuracy 

Typically  better  than  ±0.5  nm 
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Appendix  H  -  Global  Command  and  Control 
System  (GCCS) 


GCCS  is  a  joint  mandated  Command  and  Control  (C2)  automated  data  processing 
"system-of-sy stems”  designed  to  support  situational  awareness  and  crisis  planning  with 
the  use  of  an  integrated  set  of  analytic  tools  and  flexible  data  transfer  capabilities,  see 
Figure  7.  GCCS  will  be  providing  command  and  control,  communications,  computers 
and  intelligence  (C4I)  capabilities  for  Marine  Corps  commands  participating  in  joint 
planning  and  execution.  GCCS  encompasses  the  policies,  procedures,  and  systems  to 
provide  information  data  sourcing  and  monitoring,  planning,  and  executing  of 
mobilization,  deployment,  employment,  sustainment,  redeployment,  and  force 
regeneration  activities  associated  with  command  and  control  of  military 
operations.  The  GCCS  implementation  approach  provides  an  infrastructure  supporting 
migration  of  selected  Command  and  Control  (C2)  applications  into  a  client/server, 
open  system  environment. 
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Figure  7.  Global  Command  and  Control  System3 


3  From  http://www.fas.org/nuke/quide/usa/c3i/qccs.htm 
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List  of 

symbols/abbreviations/acronyms/initialisms 


AIS 

Automatic  Identification  System 

ALIX 

Atlantic  Littoral  Intelligence  Surveillance  Reconnaissance 
Experiment 

AOR 

Area  Of  Responsibility 

ASuW 

Antisubmarine  Warfare 

ASW 

Anti  Surface  submarine  Warfare 

AW 

Acoustic  Warfare 

C2 

Command  and  Control 

C4ISR 

Command,  Control,  Communications,  Computer, 
Intelligence,  Surveillance,  and  Reconnaissance 

CBS  A 

Canadian  Border  Services  Agency 

CE 

Capability  Engineering 

CMM 

Capability  Maturity  Model 

COE 

Common  Operating  Environment 

CTS 

Commercial  Traffic  Server 

DND 

Department  of  National  Defence 

DoD 

Department  of  Defense 

DRDC 

Defence  Research  and  Development  Canada 

ECMSS 

East  Coast  Maritime  Sensor  Suite 

EEZ 

Exclusive  Economic  Zone 

ELINT 

Electronic  Intelligence 

FFSE 

Future  Forces  Synthetic  Environments 
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GCCS 

Global  Command  and  Control  System 

GOC 

Government  Of  Canada 

HFSWR 

High  Frequency  Surface  Wave  Radar 

HIT 

High  Interest  Track/Target 

ISR 

Intelligence  Surveillance  Reconnaissance 

MOC 

Maritime  Operations  Centre 

MOE 

Measures  Of  Effectiveness 

MOP 

Measures  Of  Performance 

MUSIC 

Multi-Sensor  Integration  within  the  Common  Operating 
Environment 

MW 

Maritime  Warfare 

NATO 

North  Atlantic  Treaty  Organisation 

NDIA 

National  Defense  Industrial  Association 

OSWEX 

Own- ship  Weather 

OTH 

Over  The  Horizon 

RAST 

Radar  and  Application  Space  Technology 

RCMP 

Royal  Canadian  Mounted  Police 

RMP 

Recognized  Maritime  Picture 

RTB 

Research  Test  Bed 

SAR 

Search  And  Rescue 

SE 

Synthetic  Environment 

SEI 

Software  Engineering  Institute 

STANAG 

Standardisation  Agreement  (NATO) 

STRIVE 

Synthetic  Tactical  Real-Time  Interactive  Visual 
Environment 
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TDP 


Technology  Demonstration  Project 
Unmanned  Aerial  Vehicle 


UAV 
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